Overview

This page describes an overview of Lenses IAM (Identify & Access Management)

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 policy that is very open or a policy that is very granular, 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 not only actions at HQ but at lower environment levels, and to assign the same set of permissions across your whole Kafka landscape in a central place.

A role has:

• A unique name;

• A list of Permission Statements called a Policy.

Policies

A policies have:

• One or more actions;

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

• An effect: allow or deny.

name: [policy_name]
policy: #list of actions/resources/effect
- action:
  resource:
  effect:[allow|deny]      

If any effect is deny for a resource the result is always deny, the principle of least privileged applies.

A policy is defined by a YAML specification.

Example Policy

name: blue-things
policy:
  - action:
      - iam:List*
      - iam:Get*
    resource: iam:*
    effect: allow
  - action:
      - environments:Get*
      - environments:List*
      - environments:AccessEnvironment
    resource: environments:*
    effect: allow
  - action:
      - kafka:*
      - schemas:*
      - kafka-connect:*
      - kubernetes:*
      - applications:*
    resource:
      - kafka:topic/*/*/blue-*
      - kafka:consumer-group/*/*/blue-*
      - kafka:acl/*/*/*/user/blue-*
      - schemas:schema/*/*/blue-*
      - kafka-connect:cluster/*/*
      - kafka-connect:connector/*/*/blue-*
      - sql-streaming:processor/*/*/*/blue-*
      - kubernetes:cluster/*/*
      - kubernetes:namespace/*/*/*
      - applications:external-application/*/blue-*

Actions

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

An action has the format: service:operation, e.g. iam:DeleteUser

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

Operation can contain a wildcard. If so, only at the end. See IAM Reference for the available operations per service.

Resources

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

Resource-type cannot contain a combination of characters with wildcards.

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

Resource Path

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

A resource-path consists of one or more segments separated by /. 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.

The format is service:resource-type:resource-path

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.

p	s	match
"lit"	"lit"	true
"lit"	"li"	false
"lit"	"litt"	false
"lit"	"oth"	false
"*"	"some"	true
"foo*"	"foo"	true
"foo*"	"foo-bar"	true
""	""	true
"x"	""	false
""	"x"	false

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.