Principals (Users & Service accounts) receive their permissions based on their group membership.

Roles hold a set of policies, defining the permissions. Roles are assigned to groups.

Roles provide flexibility in how you want to provide access. You can create a very open policy or a very granular policy, for example, allowing operators and support engineers certain permissions to restart Connectors but denying actions that would allow them to view data or configuration options.

Roles are defined at the HQ level. This allows you to control access to actions at HQ and lower environment levels and to assign the same set of permissions across your whole Kafka landscape in a central place.

Policies

A policies have:

• One or more actions;

• One or more resource patterns that the actions apply to;

• An effect: allow or deny.

A policy is defined by a YAML specification.

Actions

Actions describe a set of actions. Concrete actions can match an Action Pattern. In this text, action and action patterns are used interchangeably.

Services

Services describe the system entity that an action applies to. Services are:

1. environments

2. kafka

3. registry

4. schemas

5. kafka-connect

6. sql-streaming

7. kubernetes

8. applications

9. alerts

10. data-policies

11. governance

12. audit

13. iam

14. administration

Operations

Resources

Resources identify which resource, in a service, that the principal is allowed or denied, to perform the operation on.

If the service is provided, resource-type can be a wildcard.

Resource ID

The resource ID identifies the resource within the context of a service and a resource type.

A resource-id consists of one or more segments separated by a slash /. A segment can be a wildcard, or contain a wildcard as a suffix of a string. If a segment is a wildcard, then remaining segments do not need to be provided, and will be assumed to be wildcards as well.

Where LRN is the Lenses Resource Name

• kafka:topic:my-env/* will be expanded to kafka:topic:my-env/*/*;

• kafka:topic:my-env/my-cluster* is invalid because the Topic segment is missing, kafka:topic:my-env/my-cluster*/topic would be valid though;

• *:topic:* is invalid, the service is not provided;

• kaf*:* and kafka:top* are invalid, service and resource-type cannot contain wildcards;

• kafka:*:foo is invalid, if the resource-type is a wildcard then resource-id cannot be set.

Evaluation

A principal (user or service account) can perform an action on a resource if:

In any of the roles it receives via group membership:

• There is any matching Permission Statement that has an effect of allow;

• And there is not any matching Permission Statement that has an effect of deny.

A Permission Statement matches an action plus resource, if:

• The action matches any of the Permission Statement's Action Patterns, AND:

• The resource matches any of the Permission Statement's Resource Patterns.

An Action matches an Action Pattern (AP) if:

• The AP is a wildcard, OR:

• The Action's service equals the AP's and the AP's operation string-matches the Action's operation.

A Resource matches a Resource Pattern (RP) if:

• The RP is a wildcard, OR:

• The Resource's services equals the RP's and the RP's resource-type is a wildcard, OR:

• The Resource's service and types equals that of the RP and resource-ids match. Resource-ids are matched by string-matching each individual segment. If the RP has a trailing wildcard segment, the remaining segments are ignored.

A string s matches p if:

• They equal character by character.

• If s or p has more non-wildcard characters than the other they don't match;

• If p contains a * suffix, any remaining characters in s are ignored.

Order of items in any collection is irrelevant during evaluation. Collections are considered sets rather than ordered lists. The following are equivalent:

• Order of Resource Patterns does not matter

• Order of Permission Statements does not matter

• Order of Roles does not matter

• Order of Groups does not matter

Examples

In the examples we're not too religious about strict JSON formatting.

Broad Allow + Specific Deny

Given:

policy:
  - effect: allow
    resource: kafka:topic:my-env/*/*
    action: ReadKafkaData
  - effect: deny
    resource: kafka:topic:*/*/forbidden-topic
    action: ReadKafkaData

A principal:

• Can ReadKafkaData on kafka:topic:my-env/the-cluster/some-topic because it is allowed and not denied;

• Cannot DeleteKafkaTopic on kafka:topic:my-env/the-cluster/some-topic because there is no allow;

• Cannot ReadKafkaData on kafka:topic:my-env/the-cluster/forbidden-topic because while it is allowed the deny kicks in.

Multiple Resources I

Given:

policy:  
  - effect: allow
    resource: [*, kafka:topic:my-cluster/*]
    action: ReadKafkaData

A principal:

• Can ReadKafkaData on kafka:topic:someone-else-cluster/their-topic because the resource matches *.

Note that here the matching can be considered "most permissive".

Multiple Resources II

Given:

policy:
  - effect: allow
    resource: [kafka:topic:my-cluster/my-topic-1, kafka:topic:my-cluster/my-topic-2]
    action: ReadKafkaData

A principal:

• Can ReadKafkaData on kafka:topic:my-cluster/my-topic-1 and kafka:topic:my-cluster/my-topic-2 because the resources match, but cannot ReadKafkaData on kafka:topic:my-cluster/my-topic-3.

User can be manually created in Lenses. Users can either be of type:

1. SSO, or

2. Basic Authentication

When creating a User, you can assign them groups membership.

Each user, once logged in can update their Name, Profile Photo and set an email address.

Create a User

To Create Service Account go to IAM->Users->New User, once created you can assign the user to a group.

You can also manage Users via the CLI and YAML, for integration in your CI/CD pipelines.

➜  lenses users
Usage:
  lenses users [command]

Aliases:
  users, usr, u

Available Commands:
  create         Creates a new user.
  delete         Deletes a user.
  get            Returns a specific user
  get-current    Returns the currently authenticated user
  list           Returns all users
  metadata       Manages user metadata.
  set-groups     Assigns the given user exactly to the provided groups, ensuring they are not part of any other groups.
  update         Updates a user.
  update-profile Allows updating fields of the user profile.

Service accounts are intended for programmatic access to Lenses.

Each service account has a key that is used to authenticate and identify the service account.

In addition you can set:

1. Description

2. Resource name - Must be unique across Lenses.

3. Key expiry

4. Regenerate the key

Key expiry can be 7, 30, 60, 90 days, 1 year or a custom expiration or no expiration at all.

Creating a Service Account

To Create Service Account go to IAM->Service Accounts->New Service Account, once created you can then assign service accounts to groups.

You can also manage Users via the CLI and YAML, for integration in your CI/CD pipelines.

API Calls

When interacting with Lenses via APIs set the service account token as in the header: