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.
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.
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:
environments
kafka
registry
schemas
kafka-connect
sql-streaming
kubernetes
applications
alerts
data-policies
governance
audit
iam
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 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.
The format is service:resource-type:resource-id
Where LRN is the Lenses Resource Name
kafka:topic:my-env/*
will be expanded tokafka: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*:*
andkafka: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:
A principal:
Can
ReadKafkaData
onkafka:topic:my-env/the-cluster/some-topic
because it is allowed and not denied;Cannot
DeleteKafkaTopic
onkafka:topic:my-env/the-cluster/some-topic
because there is no allow;Cannot
ReadKafkaData
onkafka:topic:my-env/the-cluster/forbidden-topic
because while it is allowed the deny kicks in.
Multiple Resources I
Given:
A principal:
Can
ReadKafkaData
onkafka:topic:someone-else-cluster/their-topic
because the resource matches*
.
Note that here the matching can be considered "most permissive".
Multiple Resources II
Given:
A principal:
Can
ReadKafkaData
onkafka:topic:my-cluster/my-topic-1
andkafka:topic:my-cluster/my-topic-2
because the resources match, but cannotReadKafkaData
onkafka:topic:my-cluster/my-topic-3
.
Last updated