---
title: "Configure RBAC for Elasticsearch logs and events"
description: "Configure RBAC to control access to Elasticsearch logs and events."
product: "Calico Enterprise"
version: "3.21"
section: "Observability"
canonical_url: "https://docs.tigera.io/calico-enterprise/3.21/observability/elastic/rbac-elasticsearch"
---

# Configure RBAC for Elasticsearch logs and events

## Big picture

Configure fine-grained user access controls for flow logs, audit logs, DNS logs, and intrusion detection events.

## Value

Security teams and auditors require Elasticsearch logs and associated reports. Teams responsible for threat defense (suspicious IPs and domains), may have different roles. When sharing a user interface, it is critical to provide fine-grained RBAC. Calico Enterprise lets you manage user access at the cluster, feature, and feature subset levels. For example, users without permissions to specific Elasticsearch resources (for example, DNS logs), will not see data displayed on pages that use the Elasticsearch resource.

## Concepts

### RBAC for logs and events

Elasticsearch resources are associated with the **Kubernetes API group**, `lma.tigera.io`. You can grant access to resources per cluster. The default cluster name for Calico Enterprise is, `cluster`. As shown in the following table, each Elasticsearch resource is mapped to a specific RBAC resource name within the `lma.tigera.io` API group. In the Calico Enterprise web console, Elasticsearch resources are called, **indexes or indices**.

| Elasticsearch access            | Kubernetes RBAC resource name | Description                                                                                                                                                                        |
| ------------------------------- | ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| tigera\_secure\_ee\_flows       | flows                         | Access to indices with data for Flow logs.                                                                                                                                         |
| tigera\_secure\_ee\_audit\*     | audit\*                       | Access to indices with data for both Calico Enterprise and Kubernetes audit logs. The UI currently uses this query for searching both Kubernetes and Calico Enterprise audit logs. |
| tigera\_secure\_ee\_audit\_ee   | audit\_ee                     | Access to indices with data for Calico Enterprise audit logs.                                                                                                                      |
| tigera\_secure\_ee\_audit\_kube | audit\_kube                   | Access to indices with data for Kubernetes audit logs                                                                                                                              |
| tigera\_secure\_ee\_events      | events                        | Access to indices with data for Calico Enterprise intrusion detection events.                                                                                                      |
| kibana\_login                   | kibana\_login                 | Allows an OIDC user to log in to Kibana and have read permissions for discover, visualize and dashboard.                                                                           |
| superuser                       | elasticsearch\_superuser      | Grants superuser access for all Elastic related actions, which include Kibana user and license management.                                                                         |
| tigera\_secure\_ee\_l7          | l7                            | Access to indices with data for L7 logs                                                                                                                                            |

> **SECONDARY:** Because the `lma.tigera.io` API group is used only for RBAC, and is not backed by an actual API, it does not provide access to any other Kubernetes resources.

## Before you begin

**Required**

- A `tigera-network-admin` role with full permissions to create and modify resources. For help, see [Log in to the Calico Enterprise web console](https://docs.tigera.io/calico-enterprise/3.21/operations/cnx/authentication-quickstart.md).

- To view Elasticsearch resources in the Calico Enterprise web console, users must have [minimum permissions](https://docs.tigera.io/calico-enterprise/3.21/network-policy/policy-tiers/rbac-tiered-policies.md).

## How to

- [Create access to a specific Elasticsearch resource](#create-access-to-a-specific-elasticsearch-resource)
- [Allow user access to a specific Elasticsearch resource](#allow-user-access-to-a-specific-elasticsearch-resource)
- [Verify user access to a specific Elasticsearch resource](#verify-user-access-to-a-specific-elasticsearch-resource)
- [Create access to all Elasticsearch resources](#create-access-to-all-elasticsearch-resources)
- [Allow user access to all Elasticsearch resources](#allow-user-access-to-all-elasticsearch-resources)
- [Verify user access to all Elasticsearch resources](#verify-user-access-to-all-elasticsearch-resources)

### Create access to a specific Elasticsearch resource

Create a `ClusterRole` with permissions to the resource using the table in the **Concepts** section. In this example, the ClusterRole named, `audit-ee-only` provides access to Calico Enterprise audit logs using the `resourceNames: ["audit_ee"]`. The `apiGroups: ["lma.tigera.io"]` is required.

```yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: audit-ee-only
rules:
  - apiGroups: ['lma.tigera.io']
    resources: ['cluster']
    resourceNames: ['audit_ee']
    verbs: ['get']
```

### Allow user access to a specific Elasticsearch resource

To allow a user access to a specific Elasticsearch resource, create a `ClusterRoleBinding`. In the following example, the `ClusterRoleBinding` allows user **bob** access only to the resource, Calico Enterprise audit logs (`audit-ee-only`).

```yaml
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: bob-es-access
subjects:
  - kind: User
    name: bob
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: audit-ee-only
  apiGroup: rbac.authorization.k8s.io
```

### Verify user access to a specific Elasticsearch resource

Create a `SubjectAccessReview` spec to verify user access to a specific Elasticsearch resource. In the SubjectAccessReview spec, set the following:

- group: `lma.tigera.io`
- resource: `cluster`
- verb: `get`
- resource: a Kubernetes RBAC resource name
- user: username you are verifying

> **SECONDARY:** When verifying the **`audit*` RBAC resource name** (which accesses both Calico Enterprise and Kubernetes audit logs), create a `SubjectAccessReview` **only on `audit*`**; this provides the correct verification results. Do not create a `SubjectAccessReview` to query the individual `audit_ee` or `audit_kube` resources; results ("allowed: false") do not accurately reflect user access.

```text
kubectl create -o yaml -f - <<EOF
apiVersion: authorization.k8s.io/v1
kind: SubjectAccessReview
spec:
  resourceAttributes:
    group: lma.tigera.io
    resource: cluster
    name: audit_ee
    verb: get
  user: bob
EOF
```

View the `status` and `allowed` fields to verify that the `ClusterRoleBinding` is doing what you expect. In this example, **bob** is allowed access (`allowed: true`) using the `ClusterRoleBinding`, `"bob-es-access"` for the `audit-ee-only` resource.

```yaml
apiVersion: authorization.k8s.io/v1
kind: SubjectAccessReview
metadata:
  creationTimestamp: null
spec:
  resourceAttributes:
    group: lma.tigera.io
    name: audit_ee
    resource: cluster
    verb: get
  user: bob
status:
  allowed: true
  reason: 'RBAC: allowed by ClusterRoleBinding "bob-es-access" of ClusterRole "audit-ee-only"
    to User "bob"'
```

### Create access to all Elasticsearch resources

In a `ClusterRole` resource, set the field, `resourceNames: []` to allow access to all Elasticsearch resources.

```yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: allow-all-es
rules:
  - apiGroups: ['lma.tigera.io']
    resources: ['cluster']
    resourceNames: []
    verbs: ['get']
```

### Allow user access to all Elasticsearch resources

In this example, we create a binding that allows the user `jane` access to all Elasticsearch resources.

```yaml
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: jane-allow-all-es
subjects:
  - kind: User
    name: jane
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: allow-all-es
  apiGroup: rbac.authorization.k8s.io
```

### Verify user access to all Elasticsearch resources

To verify if a user has access to all Elasticsearch resources, create a `SubjectAccessReview` and set the `name:` field with an empty string, `""` ("all").

```text
kubectl create -o yaml -f - <<EOF
apiVersion: authorization.k8s.io/v1
kind: SubjectAccessReview
spec:
  resourceAttributes:
    group: lma.tigera.io
    resource: cluster
    name: ""
    verb: get
  user: bob
EOF
```

View the `status` and `allowed` fields to verify that bob cannot access any Elasticsearch resources (`allowed: false`).

```yaml
apiVersion: authorization.k8s.io/v1
kind: SubjectAccessReview
metadata:
  creationTimestamp: null
spec:
  resourceAttributes:
    group: lma.tigera.io
    resource: cluster
    verb: get
  user: bob
status:
  allowed: false
  reason: no RBAC policy matched
```

## Additional resources

- Configure [RBAC for tiered policies](https://docs.tigera.io/calico-enterprise/3.21/network-policy/policy-tiers/rbac-tiered-policies.md).
- Learn more about the [ManagementCluster](https://docs.tigera.io/calico-enterprise/3.21/reference/installation/api.md#managementcluster) resource.