이 콘텐츠는 선택한 언어로 제공되지 않습니다.
Chapter 6. Using the User Operator
The User Operator provides a way of managing Kafka users via OpenShift resources.
6.1. Overview of the User Operator component 링크 복사링크가 클립보드에 복사되었습니다!
The User Operator manages Kafka users for a Kafka cluster by watching for KafkaUser resources that describe Kafka users and ensuring that they are configured properly in the Kafka cluster. For example:
-
if a
KafkaUseris created, the User Operator will create the user it describes -
if a
KafkaUseris deleted, the User Operator will delete the user it describes -
if a
KafkaUseris changed, the User Operator will update the user it describes
Unlike the Topic Operator, the User Operator does not sync any changes from the Kafka cluster with the OpenShift resources. Unlike the Kafka topics which might be created by applications directly in Kafka, it is not expected that the users will be managed directly in the Kafka cluster in parallel with the User Operator, so this should not be needed.
The User Operator allows you to declare a KafkaUser as part of your application’s deployment. When the user is created, the user credentials will be created in a Secret. Your application needs to use the user and its credentials for authentication and to produce or consume messages.
In addition to managing credentials for authentication, the User Operator also manages authorization rules by including a description of the user’s rights in the KafkaUser declaration.
6.2. Mutual TLS authentication 링크 복사링크가 클립보드에 복사되었습니다!
Mutual TLS authentication is always used for the communication between Kafka brokers and Zookeeper pods.
Mutual authentication or two-way authentication is when both the server and the client present certificates. AMQ Streams can configure Kafka to use TLS (Transport Layer Security) to provide encrypted communication between Kafka brokers and clients either with or without mutual authentication. When you configure mutual authentication, the broker authenticates the client and the client authenticates the broker.
TLS authentication is more commonly one-way, with one party authenticating the identity of another. For example, when HTTPS is used between a web browser and a web server, the server obtains proof of the identity of the browser.
6.2.1. When to use mutual TLS authentication for clients 링크 복사링크가 클립보드에 복사되었습니다!
Mutual TLS authentication is recommended for authenticating Kafka clients when:
- The client supports authentication using mutual TLS authentication
- It is necessary to use the TLS certificates rather than passwords
- You can reconfigure and restart client applications periodically so that they do not use expired certificates.
6.3. Creating a Kafka user with mutual TLS authentication 링크 복사링크가 클립보드에 복사되었습니다!
Prerequisites
- A running Kafka cluster configured with a listener using TLS authentication.
- A running User Operator (typically deployed with the Entity Operator).
Procedure
Prepare a YAML file containing the
KafkaUserto be created.An example
KafkaUserCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create the
KafkaUserresource in OpenShift.This can be done using
oc apply:oc apply -f your-file
oc apply -f your-fileCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Use the credentials from the secret
my-userin your application
Additional resources
- For more information about deploying the Cluster Operator, see Section 2.3, “Cluster Operator”.
- For more information about configuring a listener that authenticates using TLS see Section 3.1.6, “Kafka broker listeners”.
- For more information about deploying the Entity Operator, see Section 3.1.11, “Entity Operator”.
-
For more information about the
KafkaUserobject, seeKafkaUserschema reference.
6.4. SCRAM-SHA authentication 링크 복사링크가 클립보드에 복사되었습니다!
SCRAM (Salted Challenge Response Authentication Mechanism) is an authentication protocol that can establish mutual authentication using passwords. AMQ Streams can configure Kafka to use SASL (Simple Authentication and Security Layer) SCRAM-SHA-512 to provide authentication on both unencrypted and TLS-encrypted client connections. TLS authentication is always used internally between Kafka brokers and Zookeeper nodes. When used with a TLS client connection, the TLS protocol provides encryption, but is not used for authentication.
The following properties of SCRAM make it safe to use SCRAM-SHA even on unencrypted connections:
- The passwords are not sent in the clear over the communication channel. Instead the client and the server are each challenged by the other to offer proof that they know the password of the authenticating user.
- The server and client each generate a new challenge for each authentication exchange. This means that the exchange is resilient against replay attacks.
6.4.1. Supported SCRAM credentials 링크 복사링크가 클립보드에 복사되었습니다!
AMQ Streams supports SCRAM-SHA-512 only. When a KafkaUser.spec.authentication.type is configured with scram-sha-512 the User Operator will generate a random 12 character password consisting of upper and lowercase ASCII letters and numbers.
6.4.2. When to use SCRAM-SHA authentication for clients 링크 복사링크가 클립보드에 복사되었습니다!
SCRAM-SHA is recommended for authenticating Kafka clients when:
- The client supports authentication using SCRAM-SHA-512
- It is necessary to use passwords rather than the TLS certificates
- Authentication for unencrypted communication is required
6.5. Creating a Kafka user with SCRAM SHA authentication 링크 복사링크가 클립보드에 복사되었습니다!
Prerequisites
- A running Kafka cluster configured with a listener using SCRAM SHA authentication.
- A running User Operator (typically deployed with the Entity Operator).
Procedure
Prepare a YAML file containing the
KafkaUserto be created.An example
KafkaUserCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create the
KafkaUserresource in OpenShift.This can be done using
oc apply:oc apply -f your-file
oc apply -f your-fileCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Use the credentials from the secret
my-userin your application
Additional resources
- For more information about deploying the Cluster Operator, see Section 2.3, “Cluster Operator”.
- For more information about configuring a listener that authenticates using SCRAM SHA see Section 3.1.6, “Kafka broker listeners”.
- For more information about deploying the Entity Operator, see Section 3.1.11, “Entity Operator”.
-
For more information about the
KafkaUserobject, seeKafkaUserschema reference.
6.6. Editing a Kafka user 링크 복사링크가 클립보드에 복사되었습니다!
This procedure describes how to change the configuration of an existing Kafka user by using a KafkaUser OpenShift resource.
Prerequisites
- A running Kafka cluster.
- A running User Operator (typically deployed with the Entity Operator).
-
An existing
KafkaUserto be changed.
Procedure
Prepare a YAML file containing the desired
KafkaUser.An example
KafkaUserCopy to Clipboard Copied! Toggle word wrap Toggle overflow Update the
KafkaUserresource in OpenShift.This can be done using
oc apply:oc apply -f your-file
oc apply -f your-fileCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Use the updated credentials from the
my-usersecret in your application.
Additional resources
- For more information about deploying the Cluster Operator, see Section 2.3, “Cluster Operator”.
- For more information about deploying the Entity Operator, see Section 3.1.11, “Entity Operator”.
-
For more information about the
KafkaUserobject, seeKafkaUserschema reference.
6.7. Deleting a Kafka user 링크 복사링크가 클립보드에 복사되었습니다!
This procedure describes how to delete a Kafka user created with KafkaUser OpenShift resource.
Prerequisites
- A running Kafka cluster.
- A running User Operator (typically deployed with the Entity Operator).
-
An existing
KafkaUserto be deleted.
Procedure
Delete the
KafkaUserresource in OpenShift.This can be done using
oc delete:oc delete kafkauser your-user-name
oc delete kafkauser your-user-nameCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Additional resources
- For more information about deploying the Cluster Operator, see Section 2.3, “Cluster Operator”.
-
For more information about the
KafkaUserobject, seeKafkaUserschema reference.
6.8. Kafka User resource 링크 복사링크가 클립보드에 복사되었습니다!
The KafkaUser resource is used to declare a user with its authentication mechanism, authorization mechanism, and access rights.
6.8.1. Authentication 링크 복사링크가 클립보드에 복사되었습니다!
Authentication is configured using the authentication property in KafkaUser.spec. The authentication mechanism enabled for this user will be specified using the type field. Currently, the only supported authentication mechanisms are the TLS Client Authentication mechanism and the SCRAM-SHA-512 mechanism.
When no authentication mechanism is specified, User Operator will not create the user or its credentials.
6.8.1.1. TLS Client Authentication 링크 복사링크가 클립보드에 복사되었습니다!
To use TLS client authentication, set the type field to tls.
An example of KafkaUser with enabled TLS Client Authentication
When the user is created by the User Operator, it will create a new secret with the same name as the KafkaUser resource. The secret will contain a public and private key which should be used for the TLS Client Authentication. Bundled with them will be the public key of the client certification authority which was used to sign the user certificate. All keys will be in X509 format.
An example of the Secret with user credentials
6.8.1.2. SCRAM-SHA-512 Authentication 링크 복사링크가 클립보드에 복사되었습니다!
To use SCRAM-SHA-512 authentication mechanism, set the type field to scram-sha-512.
An example of KafkaUser with enabled SCRAM-SHA-512 authentication
When the user is created by the User Operator, the User Operator will create a new secret with the same name as the KafkaUser resource. The secret contains the generated password in the password key, which is encoded with base64. In order to use the password it must be decoded.
An example of the Secret with user credentials
For decode the generated password:
echo "Z2VuZXJhdGVkcGFzc3dvcmQ=" | base64 --decode
echo "Z2VuZXJhdGVkcGFzc3dvcmQ=" | base64 --decode
6.8.2. Authorization 링크 복사링크가 클립보드에 복사되었습니다!
Authorization is configured using the authorization property in KafkaUser.spec. The authorization type enabled for a user is specified using the type field. Currently, the only supported authorization type is simple authorization.
If no authorization is specified, the User Operator does not provision any access rights for the user.
6.8.2.1. Simple authorization 링크 복사링크가 클립보드에 복사되었습니다!
Simple authorization uses the default Kafka authorization plugin, SimpleAclAuthorizer.
To use simple authorization, set the type property to simple in KafkaUser.spec.
ACL rules
SimpleAclAuthorizer uses ACL rules to manage access to Kafka brokers.
ACL rules grant access rights to the user, which you specify in the acls property.
An AclRule is specified as a set of properties:
resourceThe
resourceproperty specifies the resource that the rule applies to.Simple authorization supports four resource types, which are specified in the
typeproperty:-
Topics (
topic) -
Consumer Groups (
group) -
Clusters (
cluster) -
Transactional IDs (
transactionalId)
For Topic, Group, and Transactional ID resources you can specify the name of the resource the rule applies to in the
nameproperty.Cluster type resources have no name.
A name is specified as a
literalor aprefixusing thepatternTypeproperty.-
Literal names are taken exactly as they are specified in the
namefield. -
Prefix names use the value from the
nameas a prefix, and will apply the rule to all resources with names starting with the value.
-
Topics (
typeThe
typeproperty specifies the type of ACL rule,allowordeny.The
typefield is optional. Iftypeis unspecified, the ACL rule is treated as anallowrule.operationThe
operationspecifies the operation to allow or deny.The following operations are supported:
- Read
- Write
- Delete
- Alter
- Describe
- All
- IdempotentWrite
- ClusterAction
- Create
- AlterConfigs
- DescribeConfigs
Only certain operations work with each resource.
For more details about
SimpleAclAuthorizer, ACLs and supported combinations of resources and operations, see Authorization and ACLs.hostThe
hostproperty specifies a remote host from which the rule is allowed or denied.Use an asterisk (
*) to allow or deny the operation from all hosts. Thehostfield is optional. Ifhostis unspecified, the*value is used by default.
For more information about the AclRule object, see AclRule schema reference.
An example KafkaUser
6.8.2.2. Super user access to Kafka brokers 링크 복사링크가 클립보드에 복사되었습니다!
If a user is added to a list of super users in a Kafka broker configuration, the user is allowed unlimited access to the cluster regardless of any authorization constraints defined in ACLs.
For more information on configuring super users, see authentication and authorization of Kafka brokers.
6.8.3. Additional resources 링크 복사링크가 클립보드에 복사되었습니다!
-
For more information about the
KafkaUserobject, seeKafkaUserschema reference. - For more information about the TLS Client Authentication, see Section 6.2, “Mutual TLS authentication”.
- For more information about the SASL SCRAM-SHA-512 authentication, see Section 6.4, “SCRAM-SHA authentication”.