Security

Understand Lenses security and IAM model

Lenses includes a built-in IAM model. Use it to control what users and service accounts can do.

Permissions are assigned through groups and roles. Policies define which actions are allowed or denied on specific resources.

How IAM works

Use this flow to grant access:

1. Create a group.

2. Add one or more roles to that group.

3. Add policies to each role.

4. Add users or service accounts to the group.

Users and service accounts inherit permissions from their group membership. You cannot assign roles directly to an individual account.

Managing IAM resources

Open IAM from the left navigation to create and manage groups, roles, users, and service accounts.

Use the navigation tree to browse resources. Open items in tabs to inspect, update, or delete them.

You can create from either the listing or by the nav tree actions buttons.

Groups

Groups are containers for:

• users

• service accounts

• roles

A group does not hold permissions by itself. Permissions come from the roles attached to that group.

Roles

Roles collect permissions that you want to reuse.

Add one or more policies to a role. Then attach that role to a group.

Use roles to keep access consistent across teams and services.

Policies

Policies define what a user or service account can do on a resource.

Each policy combines:

• one or more action values

• a resource scope

• an effect

Actions

An action is the operation a user or service account can perform.

Use the format:

service:operation

Example:

policy:
  - action:
      - kafka:ListTopics

Use * to match all actions.

For the full action list, see Permission Reference.

Resource

A resource limits a policy to a specific entity or set of entities.

For example, to scope access to topics that start with red, use the resource field with a matching value.

Use * to match all resources.

For supported resource formats, see Permission Reference.

Effect

The effect decides whether a policy grants or blocks access.

Supported values are:

• allow

• deny

If an action is not explicitly allowed, it is denied by default.

If any matching policy sets deny, that deny takes precedence.

Example policy

This example shows the common policy shape:

policy:
  - name: red-topic-reader
    effect: allow
    resource: red*
    action:
      - kafka:ListTopics

Check the permission reference for the exact schema and supported values.

For a full reference, see IAM Reference

For example policies, see Example Policies

Users

Users are human accounts that sign in to Lenses.

Assign each user to one or more groups. The user inherits the permissions of those groups.

Service Accounts

Service accounts are non-human identities for applications and automation.

Assign service accounts to groups in the same way as users. They inherit the permissions of those groups.

Use service accounts for integrations, scheduled jobs, and CI/CD workflows.

Use separate service accounts per application or workload. This keeps permissions scoped and makes access easier to review.

API Calls

When calling the Lenses APIs, send the service account token in the Authorization header:

Authorization: Bearer <service_account_token>