SupportConsoleDevelopersStart a trialContact

Chapter 1. Control access to Loki logs

Control which users can access logs stored in Loki by configuring role-based access control.

1.1. Fine grained access for Loki logs
Copy link

Configure fine-grained access to logs using cluster-wide policies, namespace-scoped policies, or custom admin groups.

The Red Hat OpenShift Logging Operator does not grant all users access to logs by default. As an administrator, configure your users' access unless you upgraded the Operator and prior configurations are in place. Depending on your configuration and need, configure fine-grained access to logs by using the following:

  • Cluster wide policies
  • Namespace scoped policies
  • Creation of custom admin groups

As an administrator, you need to create the role bindings and cluster role bindings appropriate for your deployment. The Red Hat OpenShift Logging Operator provides the following cluster roles:

  • cluster-logging-application-view grants permission to read application logs.
  • cluster-logging-infrastructure-view grants permission to read infrastructure logs.
  • cluster-logging-audit-view grants permission to read audit logs.

If you have upgraded from a prior version, an additional cluster role logging-application-logs-reader and associated cluster role binding logging-all-authenticated-application-logs-reader provide backward compatibility, allowing any authenticated user read access in their namespaces.

Note

Users with access by namespace must provide a namespace when querying application logs.

1.1.1. Cluster wide access
Copy link

Cluster role binding resources reference cluster roles, and set permissions cluster wide.

Example ClusterRoleBinding

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: logging-all-application-logs-reader
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-logging-application-view
subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io

name
Additional ClusterRoles are cluster-logging-infrastructure-view, and cluster-logging-audit-view.
subjects
Specifies the users or groups this object applies to.

1.1.2. Namespaced access
Copy link

Use RoleBinding resources with ClusterRole objects to define the namespaces for which a user or group can access logs.

Example RoleBinding for a User

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: allow-read-logs
  namespace: log-test-0
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-logging-application-view
subjects:
- kind: User
  apiGroup: rbac.authorization.k8s.io
  name: testuser-0

namespace
Specifies the namespace this RoleBinding applies to.

Example RoleBinding for a ServiceAccount

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: allow-sa-read-logs
  namespace: log-test-0
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-logging-application-view
subjects:
- kind: ServiceAccount
  name: log-reader-sa
  namespace: log-test-0

namespace
Specifies the namespace this RoleBinding applies to.
name
The ServiceAccount must have permission to list projects for namespace-scoped log access.
Note

When granting namespace-scoped access to a ServiceAccount, also grant the service account permission to list projects. Create a ClusterRoleBinding that binds the service account to the self-provisioner cluster role or create a custom ClusterRole with project list permissions.

1.1.3. Custom admin group access
Copy link

For large deployments with several users who require broader permissions, create a custom group by using the adminGroup field. Users who are members of any group specified in the adminGroups field of the LokiStack CR have administrator permissions.

Administrator users have access to all application logs in all namespaces, if they also get assigned the cluster-logging-application-view role.

Note

To grant cluster-wide log access to a ServiceAccount, add the service account’s group to the adminGroups field in the LokiStack CR. The service account group follows the format system:serviceaccounts:<namespace> for all service accounts in a namespace, or system:serviceaccount:<namespace>:<name> for a specific service account.

Example LokiStack CR

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  tenants:
    mode: openshift-logging
    openshift:
      adminGroups:
      - cluster-admin
      - custom-admin-group
      - system:serviceaccount:openshift-logging:log-reader-sa

mode
Custom admin groups are only available in this mode.
adminGroups
Entering an empty list [] value for this field disables admin groups.
custom-admin-group
Overrides the default groups (system:cluster-admins, cluster-admin, dedicated-admin)
system:serviceaccount:openshift-logging:log-reader-sa
Grants cluster-wide log access to a specific ServiceAccount.

Create a new group to assign cluster-admin user role permissions.

Important

Querying application logs for multiple namespaces as a cluster-admin user, where the sum total of characters of all of the namespaces in the cluster is greater than 5120, results in the error Parse error: input size too long (XXXX > 5120). For better control over access to logs in LokiStack, make the cluster-admin user a member of the cluster-admin group. If the cluster-admin group does not exist, create it and add the desired users to it.

Use the following procedure to create a new group for users with cluster-admin permissions.

Procedure

  1. Enter the following command to create a new group: 

    $ oc adm groups new cluster-admin

  2. Enter the following command to add the required user to the cluster-admin group: 

    $ oc adm groups add-users cluster-admin <username>

  3. Enter the following command to add cluster-admin user role to the group: 

    $ oc adm policy add-cluster-role-to-group cluster-admin cluster-admin
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Legal Notice

Theme

© 2026 Red HatBack to top