This feature is available with Conduktor Scale Plus only.

​
Overview

Self-service helps you scale Kafka usage in your organization by facilitating collaboration between the central platform team and application teams. It simplifies and automates processes, establishes clear rules/ways of working and standardizes the creation and management of Kafka resources. This approach brings governance into your enterprise through concepts like ownership and applications, delegating operations to the application teams rather than the central platform team.

​
Benefits for central platform teams

  • Define general rules of the game
  • Enforce naming conventions
  • Safeguard from invalid or expensive configurations (e.g. high partition numbers, etc.)
  • Declare applications and their rights

​
Benefits for applications teams

  • Autonomy and ownership over your resources
  • Isolation using application namespaces
  • Collaboration through delegating permissions without the need to interact with the central platform team
  • Discoverability through topic catalog in Console
Check out Self-service resource reference.

​
Concepts

Self-service relies on a central concept, the Application, which dictates ownership of Kafka resources. Here are the relationships between Self-service resources. Self-service Concepts

​
Central platform team resources

​
Application

An application represents a streaming app or data pipeline that is responsible for producing, consuming or processing data from Kafka. Applications give business context to Kafka resources (topics, consumer groups and subjects) that directly relate to the functioning of that application or pipeline. Example 
---
apiVersion: "self-service/v1"
kind: "Application"
metadata:
  name: "clickstream-app"
spec:
  title: "Clickstream App"
  description: "Clickstream records user’s clicks through their journey on our website"
  owner: "clickstream-group"            # technical-id of the Console Group

​
Application instance

Applications are generally deployed to one or more Kafka clusters, typically to align with the organization’s development cycle or environments. We call this concept the application instance. Each application instance:
  • is linked to a Kafka cluster and a service account
  • has ownership of Kafka resources (topics, consumer groups, subjects)
  • grants permissions for
    • the service account, using Kafka ACLs (Read and Write on Topics, Read on ConsumerGroups) and
    • the application owner group, using RBAC (Admin permission) in Console
Example 
# Application Instance (dev environment)
---
apiVersion: "self-service/v1"
kind: "ApplicationInstance"
metadata:
  application: "clickstream-app"
  name: "clickstream-app-dev"
spec:
  cluster: "shadow-it"
  serviceAccount: "sa-clickstream-dev"
  resources:
    - type: TOPIC
      name: "click."
      patternType: PREFIXED
    - type: CONSUMER_GROUP
      name: "click."
      patternType: PREFIXED

​
Application instance policies

Application instance policies restrict the creation of resources following certain rules. These rules can be related to Kafka configs but can also apply to metadata. Example 
# Policies that restrict the application to a certain range of configurations
# on topic configs, but also on topic metadata
---
apiVersion: "self-service/v1"
kind: "TopicPolicy"
metadata:
  name: "generic-dev-topic"
spec:
  policies:
    metadata.labels.data-criticality:
      constraint: OneOf
      values: ["C0", "C1", "C2"]
    spec.configs.retention.ms:
      constraint: "Range"
      max: 42
      min: 3

​
Application team resources

Once an application and application instance are defined, application teams can organize and structure their applications as they see fit. There are two groups of resources where application teams are given autonomy:
  • Kafka-related resources: Topic, Subject, Connector, ApplicationInstancePermission.
  • Console-related resources: in particular ApplicationGroup, allowing to define internally who can do what within the team.

​
Kafka resources

This is how application teams can create Kafka resources they need for their applications. 
# Topic example
---
apiVersion: kafka/v2
kind: "Topic"
metadata:
  cluster: "shadow-it"
  name: "click.screen-events"
spec:
  replicationFactor: 3
  partitions: 6
  configs:
    min.insync.replicas: "2"
    cleanup.policy: "delete"
    retention.ms: "60000"

​
Application instance permissions

Application instance permissions lets teams collaborate with each other. Deploying this object will grant permission to the grantedTo application instance to:
  • its service account (Kafka ACL)
  • the application team members in Console
Example 
# Read permission granted to the Heatmap Application on click.screen-events topic
---
apiVersion: self-service/v1
kind: "ApplicationInstancePermission"
metadata:
  application: "clickstream-app"
  appInstance: "clickstream-app-dev"
  name: "clickstream-app-dev-to-heatmap"
spec:
  resource:
    type: TOPIC
    name: "click.screen-events"
    patternType: LITERAL
  permission: READ
  grantedTo: heatmap-app-dev

​
Application group

Create an application group to directly reflect how your application operates. You can create as many application groups as required to restrict or represent the different teams that use Console on your application. For example:
  • support team with only Read Access in production
  • devOps team with extended access across all environments
  • engineering team with higher permissions in dev environment
Example 
# Permissions granted to Console users in the group, CP-COMPANY-CLICKSTREAM-SUPPORT, for the clickstream-app application
---
apiVersion: self-service/v1
kind: "ApplicationGroup"
metadata:
  application: "clickstream-app"
  name: "clickstream-support"
spec:
  displayName: Support Clickstream
  description: |
    Members of the Support Group are allowed:
      Read access on all the resources
      Can restart owned connectors
      Can reset offsets
  permissions:
    - appInstance: clickstream-app-dev
      resourceType: TOPIC
      resourcePatternType: "LITERAL"
      resourcePattern: "*" # All owned and subscribed topics
      permissions: ["topicViewConfig", "topicConsume"]
    - appInstance: clickstream-app-dev
      resourceType: CONSUMER_GROUP
      resourcePatternType: "LITERAL"
      resourcePattern: "*" # All owned consumer groups
      permissions: ["consumerGroupCreate", "consumerGroupReset", "consumerGroupDelete", "consumerGroupView"]
    - appInstance: clickstream-app-dev
      resourceType: CONNECTOR
      resourcePatternType: "LITERAL"
      resourcePattern: "*" # All owned connectors
      permissions: ["kafkaConnectorViewConfig", "kafkaConnectorStatus", "kafkaConnectPauseResume", "kafkaConnectRestart"]
  members:
    - user1@company.org
    - user2@company.org
  externalGroups:
    - GP-COMPANY-CLICKSTREAM-SUPPORT

​
Resource labels

Labels are key value pairs with no constraints that help you organize and surface business metadata in Console. We recommend that all resources that can be created using the Conduktor CLI are annotated with metadata in the form of labels. Find out which resources are currently supported. Example 
# Topic annotated with useful metadata
---
apiVersion: kafka/v2
kind: "Topic"
metadata:
  cluster: "shadow-it"
  name: clickstream.events
  labels:
    description: "A description for what kind of data this topic contains."
    business-data-classification: C2
    business-doc-url: "https://confluence.company.org/display/CLICK/Kafka"
    application-code: CLK
    environment-code: dev
spec:
  replicationFactor: 3
  partitions: 6
  configs:
    min.insync.replicas: "2"
    cleanup.policy: "delete"
    retention.ms: "60000"

​
Limited ownership mode

To help organizations transition to Self-service more easily, we’ve added a new attribute to ApplicationInstance to let platform teams decide the level of autonomy to provide to application teams.
  • ownershipMode: ALL (default value): delegates all permissions related to that resource to the application team.
  • ownershipMode: LIMITED: delegates only a subset of the available permissions to the application team.
This is especially useful if the central team have a centralized repository and an existing workflow for a topic (or other resource) creation and wants to own that part of the process. You can provide Self-service while still having application teams go through their pipeline for topic creation, instead of Self-service.
Permissions with ownershipMode: LIMITEDDescription
Topic
topicEditConfigPermission to edit the topic configuration.
topicCreatePermission to create a new topic.
topicDeletePermission to delete the topic.
topicAddPartitionPermission to add partitions to the topic.
Subject
subjectCreateUpdatePermission to create or update the subject.
subjectDeletePermission to delete the subject.
subjectEditCompatibilityPermission to edit the subject compatibility settings.
Consumer Group
consumerGroupCreatePermission to create a new consumer group.
consumerGroupDeletePermission to delete the consumer group.
Kafka Connect
kafkaConnectorEditConfigPermission to edit the Kafka Connect configuration.
kafkaConnectorDeletePermission to delete connectors.
kafkaConnectorCreatePermission to create new connectors.

​
Self-service UI

Self-service is currently principally managed with the Conduktor CLI. The Console UI reconciles actions executed via the CLI to provide read-only views in the Application Catalog and Topic Catalog pages in Console. This promotes discoverability of Kafka resources with business context within your organization. Self-service UI
Self-service UI is almost entirely read-only for now. Use the CLI to interact with the product.

​
Topic Catalog page

In Console, the Topic Catalog page lets you search through the topics marked as public deployed in your organization. You can filter by application, Kafka cluster and the topic metadata. TopicCatalog

​
Application Catalog page

In Console, the Application Catalog page lets you search through applications deployed in your organization. You can search by any available element such as owner and click on a required application.

​
Application Catalog list

The list page shows all applications deployed in your organization. You can search by any element available in the list: name, description, owner. Application Catalog Click on an application to get to its details page.

​
Application details

The application details page summarizes all the information that relates to that application:
  • general information (like name)
  • application instances and ownership
  • subscribed topics
  • shared topics
  • application groups
If you belong to the owner group of the application, you can generate application instance API keys to be used with the Conduktor CLI to create resources: App details

​
Application instance

The application instance details page summarizes all the information relating to the specific application instance:
  • ownership and resource policies
  • external access information
  • resources owned by the application instance
  • alerts related to the application instance
  • related API keys

​
Application groups

The application groups details page offers access management options:
  • Members tab: manage group membership, making it easier to control who has access to application resources.
  • Resource access tab: granular control over topic, consumer group, subject and connector permissions for precise access management.
  • External groups tab: application groups can map to external groups for streamlined access management.
Application Groups

​
Audit log events

Event typeDescription
SelfService.Application.CreateSelf-service application is created.
SelfService.Application.UpdateSelf-service application is updated.
SelfService.Application.UpsertSelf-service application is created or updated.
SelfService.Application.DeleteSelf-service application is deleted.
SelfService.ApplicationInstance.CreateSelf-service application instance is created.
SelfService.ApplicationInstance.UpdateSelf-service application instance is updated.
SelfService.ApplicationInstance.DeleteSelf-service application instance is deleted.
SelfService.ApplicationInstanceApiKey.CreateSelf-service application instance API key is created.
SelfService.ApplicationInstanceApiKey.DeleteSelf-service application instance API key is deleted.
SelfService.ApplicationGroup.CreateSelf-service application group is created.
SelfService.ApplicationGroup.UpdateSelf-service application group is updated.
SelfService.ApplicationGroup.DeleteSelf-service application group is deleted.
SelfService.ApplicationPolicy.CreateSelf-service application policy is created.
SelfService.ApplicationPolicy.UpdateSelf-service application policy is updated.
SelfService.ApplicationPolicy.DeleteSelf-service application policy is deleted.
SelfService.ApplicationInstancePermission.CreatePermissions are created for an app instance.
SelfService.ApplicationInstancePermission.DeletePermissions are deleted for an app instance.
SelfService.ServiceAccount.CreateService account is created.
SelfService.ServiceAccount.UpdateService account is updated.
SelfService.ServiceAccount.DeleteService account is deleted.