Application
An application represents a streaming app or data pipeline that’s responsible for producing, consuming or processing data in Kafka. In Self-service, it’s used as a method to organize and re-group multiple deployments of the same application (dev, prod) or different microservices that belong to the same team under one umbrella.- API key(s): AdminToken
- Managed with: API, CLI, TF
- Labels support: Full
spec.owner
is a valid Console group- Delete has to fail if there are associated
ApplicationInstance
- None, deploying this object will only create the application in Console that can be managed on the Application Catalog page.
ApplicationInstance
Application instance represents an actual deployment of an application on a Kafka cluster for a service account. This is the core concept of Self-service, as it ties everything together: Kafka cluster, service account, ownership of resources and policies.- API key(s): AdminToken
- Managed with: API, CLI, TF
- Labels support: Full
metadata.application
is a valid application.spec.cluster
is a valid Console cluster technical Id.spec.cluster
is immutable (can’t be updated after creation).spec.serviceAccount
(optional). If already used by another AppInstance on the the samespec.cluster
, it can’t be set.spec.applicationManagedServiceAccount
(optional), default isfalse
. If set totrue
, the service account ACLs will be managed by the application owners directly instead of being synchronized by the ApplicationInstance. Find out more about managed service account.spec.topicPolicyRef
(optional), if defined, has to be a valid list of TopicPolicy.spec.policyRef
(optional), if set, has to be a valid list of ResourcePolicy.spec.defaultCatalogVisibility
(optional), default isPUBLIC
. Can bePUBLIC
orPRIVATE
.spec.resources[].type
can beTOPIC
,CONSUMER_GROUP
,SUBJECT
orCONNECTOR
:spec.resources[].connectCluster
is only mandatory whentype
isCONNECTOR
;spec.resources[].connectCluster
is a valid Connect cluster linked to the Kafka clusterspec.cluster
.
spec.resources[].patternType
can bePREFIXED
orLITERAL
.spec.resources[].name
has to not overlap with any other ApplicationInstance on the same cluster. I.e.: if there’s already an owner forclick
, this is forbidden:click.orders.
: resource is a child-resource ofclick
cli
: resource is a parent-resource ofclick
spec.resources[].ownershipMode
(optional), default isALL
. Can beALL
orLIMITED
.
- Console
- Members of the owner group can create application API keys from the UI.
- Resources with
ownershipMode
set toALL
: ApplicationInstance is given all permissions in the UI and the CLI over the owned resources. - Resources with
ownershipMode
set toLIMITED
: ApplicationInstance is restricted the create/update/delete permissions in the UI and the CLI over the owned resources:- can’t use the CLI
apply
command - can’t create/delete the resource in the UI
- everything else (restart connector, browse and produce from topic, etc.) is still available. Find out more about ownership.
- can’t use the CLI
- Kafka
- Service account is granted the following ACLs over the declared resources depending on the type:
- Topic:
READ
,WRITE
andDESCRIBE_CONFIGS
- ConsumerGroup:
READ
- Topic:
- Service account is granted the following ACLs over the declared resources depending on the type:
ApplicationInstancePermission
Define permissions for the application instance to enable collaboration between teams.- API key(s): AdminToken, AppToken
- Managed with: API, CLI, TF
- Labels support: Missing
spec
is immutable:- once created, you’ll only be able to update its metadata. This is to protect you from making a change that could impact an external application.
- this resource affects target ApplicationInstance’s Kafka service account ACLs.
- to edit this resource, delete and re-create it.
spec.resource.type
can beTOPIC
.spec.resource.patternType
can bePREFIXED
orLITERAL
.spec.resource.name
has to reference any ‘sub-resource’ ofmetadata.appInstance
. For example, if you’re the owner of theclick.
prefix, you can grantREAD
orWRITE
access to:- the whole
click.
prefix, - a sub prefix
click.orders.
, - a literal topic name
click.orders.france
.
- the whole
spec.userPermission
can beREAD
,WRITE
orNONE
.spec.serviceAccountPermission
can beREAD
,WRITE
orNONE
.spec.userPermission
can beREAD
orWRITE
.spec.serviceAccountPermission
can beREAD
orWRITE
.spec.grantedTo
has to be an ApplicationInstance on the same Kafka cluster asmetadata.appInstance
.
- Console
- Members of the
grantedTo
ApplicationInstance are given the associated permissions (Read
/Write
) in the UI over the resources.
- Members of the
- Kafka
- Service account of the
grantedTo
ApplicationInstance is granted to the following ACLs over theresource
, depending on thespec.permission
:READ
: READ, DESCRIBE_CONFIGSWRITE
: READ, WRITE, DESCRIBE_CONFIGS
- Service account of the
ApplicationGroup
Creates an application group to directly reflect how your application operates. You can create as many application groups as required - to restrict or enable the different teams that use Console. For example:-
the support team can only have
Read
access in production environment, - the devOps team has extended access across all environments,
- the engineering team is granted higher permissions in dev environment only.
- API key(s): “AdminToken”, “AppToken”
- Managed with: API, CLI, UI, TF
- Labels support: “MissingLabelSupport”
Example
spec.permissions[].appInstance
has to be an application instance associated with this application (metadata.application
).spec.permissions[].resourceType
can beTOPIC
,SUBJECT
,CONSUMER_GROUP
orCONNECTOR
. When set toCONNECTOR
, an additional fieldspec.permissions[].connectCluster
is mandatory and has to be a valid KafkaConnectCluster name.spec.permissions[].patternType
can bePREFIXED
orLITERAL
.spec.permissions[].name
has to reference any ‘sub-resource’ ofmetadata.appInstance
or any subscribed topic. Use*
to include to all owned and subscribed resources associated to this appInstance.spec.permissions[].permissions
are valid permissions.spec.members
has to be an email addresses of members that you want to add to this group.spec.externalGroups
a list of LDAP or OIDC groups to sync with this Console group. Members added this way will not appear inspec.members
list.spec.externalGroupRegex
a list of regex patterns that can match to a series of LDAP or OIDC groups to sync with this Console group. Members added this way will not appear inspec.members
list.
- Console
- Members of the ApplicationGroup are given the associated permissions in the UI over the resources.
- Members of the LDAP or OIDC groups will be automatically added or removed upon login.
Application-managed service account
The Self-service service account is not configured by the central team at theApplicationInstance
level.
Instead, the central platform team decides to delegate this responsibility to the application team, which needs to declare their own service account(s) and associated ACLs within the limits of what the ApplicationInstance
is allowed to do.
- API key(s): AppToken
- Managed with: API, CLI
- Labels support: Missing
- a service account is claimed by the first application team declaring it.
- ACL operations that are not aligned with Self-service approach or would prevent configured policies to apply, are not allowed on service account:
- Topic: topic name has to refer to a topic owned by ApplicationInstance or allowed by granted ApplicationInstancePermission:
Describe
,DescribeConfigs
,Read
,Write
. - Consumer group: resource name has to refer to a consumer group owned by ApplicationInstance with
Describe
andRead
. - Cluster:
Describe
andDescribeConfigs
. - Delegation token and Transactional Id: both are out of scope, have to be assigned by a central team.
- Topic: topic name has to refer to a topic owned by ApplicationInstance or allowed by granted ApplicationInstancePermission:
- When an ApplicationInstancePermission is removed, we don’t drop the ACLs on the ServiceAccount. Instead, consecutive CLI calls to apply the resource will fail.
TopicPolicy
Topic policies force application teams to conform to topic rules, set at theirApplicationInstance
level. Typical use cases include:
- safeguarding from invalid or risky topic configuration
- enforcing a naming convention
- enforcing metadata
Topic policies are not applied automatically. You have to explicitly link them to an ApplicationInstance with
spec.topicPolicyRef
.- API key(s): AdminToken
- Managed with: API, CLI, TF
- Labels support: Partial
spec.policies
require YAML paths that are paths to the topic resource YAML. For example:metadata.name
to create constraints on topic namemetadata.labels.<key>
to create constraints on topic label<key>
spec.partitions
to create constraints on partitions numberspec.replicationFactor
to create constraints on replication factorspec.configs.<key>
to create constraints on topic config<key>
spec.policies.<key>.constraint
can beRange
,OneOf
orMatch
Topic policy constraints
There are currently five available constraints:Range
validates a range of numbersOneOf
validates against a list of predefined optionsNoneOf
rejects a value if it matches any item in the listMatch
validates using a regex (regular expression)AllowedKeys
limits a set of keys in the dictionaries
Range
Validates whether the property belongs to a range of numbers (inclusive):- 3600000 (min)
- 36000000 (between min and max)
- 604800000 (max)
- 60000 (below min)
- 999999999 (above max)
OneOf
Validates whether the property is one of the expected values:delete
compact
delete, compact
(valid in Kafka but not allowed by policy)deleet
(typo)
Match
Validates the property against a regex:wikipedia.links.avro
wikipedia.products.json
notwikipedia.products.avro2
:^
and$
prevents anything before and after the patternwikipedia.all-products.avro
:(?<event>[a-z0-9]+)
prevents anything else than lowercase letters and digits
AllowedKeys
Validates whether the keys are within an allowed key list. Applies to dictionary type (Key/Value maps). Can be used onspec.configs
and metadata.labels
.
min.insync.replicas
is not an allowed key in spec.configs
):
Optional flag
Constraints can be marked as optional. In this scenario, the constraint will only be validated if the field exists. E.g.:insync.replicas
:
ResourcePolicy
Resource policies enforce rules on theApplicationInstance
level. Typical use case include:
- safeguarding from invalid or risky topic or connector configuration
- enforcing naming conventions
- enforcing metadata
Resource policies are not applied automatically. You have to explicitly link them to an ApplicationInstance or Application with
spec.policyRef
.- API key(s): AdminToken
- Managed with: API, CLI, TF
- Labels support: Partial
spec.targetKind
can beTopic
,Connector
,Subject
orApplicationGroup
.spec.rules[].condition
is a valid CEL expression and will be evaluated against the resource.spec.rules[].errorMessage
is a string that will be displayed when the condition is not met.
Moving from TopicPolicy
To replicate the behavior of the TopicPolicy with theResourcePolicy
, here’s how you can transform the different policies:
Range constraint
Before:Value constraint
Before:In list constraint
Before:Regex constraint
Before:Tips for CEL expressions
There are multiple things to should consider when writing CEL expressions in the context of resource policies:-
For field-like configuration value/label (that you don’t know the type of) and want to compare to a number, convert it to a string and then to an int like this:
int(string(spec.configs["retention.ms"]))
. -
For field key that contains dots
.
or dashes-
, you have to access them with the[]
operator:metadata.labels["data-criticality"]
. -
For field-like label key/config that can be absent, we recommend adding a check to see if the field is present:
has(metadata.labels.criticality) && {your condition}
. If the field has a dot or dash, use"retention.ms" in spec.configs && {your condition}
.