이 콘텐츠는 선택한 언어로 제공되지 않습니다.
Chapter 6. Using the User Operator
When you create, modify or delete a user using the KafkaUser
resource, the User Operator ensures those changes are reflected in the Kafka cluster.
6.1. Kafka user resource
The KafkaUser
resource is used to configure the authentication mechanism, authorization mechanism, and access rights for a user.
The full schema for KafkaUser
is described in KafkaUser
schema reference.
6.1.1. User authentication
Authentication is configured using the authentication
property in KafkaUser.spec
. The authentication mechanism enabled for the user is specified using the type
field.
Supported authentication mechanisms:
- TLS client authentication
- SCRAM-SHA-512 authentication
When no authentication mechanism is specified, the User Operator does not create the user or its credentials.
Additional resources
6.1.1.1. TLS Client Authentication
To use TLS client authentication, you set the type
field to tls
.
An example KafkaUser
with TLS client authentication enabled
apiVersion: kafka.strimzi.io/v1beta1 kind: KafkaUser metadata: name: my-user labels: strimzi.io/cluster: my-cluster spec: authentication: type: tls # ...
When the user is created by the User Operator, it creates a new Secret with the same name as the KafkaUser
resource. The Secret contains a private and public key for TLS client authentication. The public key is contained in a user certificate, which is signed by the client Certificate Authority (CA).
All keys are in X.509 format.
Secrets provide private keys and certificates in PEM and PKCS #12 formats. For more information on securing Kafka communication with Secrets, see Chapter 12, Security.
An example Secret
with user credentials
apiVersion: v1 kind: Secret metadata: name: my-user labels: strimzi.io/kind: KafkaUser strimzi.io/cluster: my-cluster type: Opaque data: ca.crt: # Public key of the client CA user.crt: # User certificate that contains the public key of the user user.key: # Private key of the user user.p12: # PKCS #12 archive file for storing certificates and keys user.password: # Password for protecting the PKCS #12 archive file
6.1.1.2. SCRAM-SHA-512 Authentication
To use SCRAM-SHA-512 authentication mechanism, you set the type
field to scram-sha-512
.
An example KafkaUser
with SCRAM-SHA-512 authentication enabled
apiVersion: kafka.strimzi.io/v1beta1 kind: KafkaUser metadata: name: my-user labels: strimzi.io/cluster: my-cluster spec: authentication: type: scram-sha-512 # ...
When the user is created by the User Operator, it creates 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 Secret
with user credentials
apiVersion: v1 kind: Secret metadata: name: my-user labels: strimzi.io/kind: KafkaUser strimzi.io/cluster: my-cluster type: Opaque data: password: Z2VuZXJhdGVkcGFzc3dvcmQ= # Generated password
Decoding the generated password:
echo "Z2VuZXJhdGVkcGFzc3dvcmQ=" | base64 --decode
6.1.2. User authorization
User authorization is configured using the authorization
property in KafkaUser.spec
. The authorization type enabled for a user is specified using the type
field.
If no authorization is specified, the User Operator does not provision any access rights for the user.
To use simple authorization, you set the type
property to simple
in KafkaUser.spec
. Simple authorization uses the default Kafka authorization plugin, SimpleAclAuthorizer
.
Alternatively, if you are using OAuth 2.0 token based authentication, you can also configure OAuth 2.0 authorization.
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:
resource
The
resource
property specifies the resource that the rule applies to.Simple authorization supports four resource types, which are specified in the
type
property:-
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
name
property.Cluster type resources have no name.
A name is specified as a
literal
or aprefix
using thepatternType
property.-
Literal names are taken exactly as they are specified in the
name
field. -
Prefix names use the value from the
name
as a prefix, and will apply the rule to all resources with names starting with the value.
-
Topics (
type
The
type
property specifies the type of ACL rule,allow
ordeny
.The
type
field is optional. Iftype
is unspecified, the ACL rule is treated as anallow
rule.operation
The
operation
specifies 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.host
The
host
property specifies a remote host from which the rule is allowed or denied.Use an asterisk (
*
) to allow or deny the operation from all hosts. Thehost
field is optional. Ifhost
is unspecified, the*
value is used by default.
For more information about the AclRule
object, see AclRule
schema reference.
An example KafkaUser
with authorization
apiVersion: kafka.strimzi.io/v1beta1 kind: KafkaUser metadata: name: my-user labels: strimzi.io/cluster: my-cluster spec: # ... authorization: type: simple acls: - resource: type: topic name: my-topic patternType: literal operation: Read - resource: type: topic name: my-topic patternType: literal operation: Describe - resource: type: group name: my-group patternType: prefix operation: Read
6.1.2.1. 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.1.3. User quotas
You can configure the spec
for the KafkaUser
resource to enforce quotas so that a user does not exceed access to Kafka brokers based on a byte threshold or a time limit of CPU utilization.
An example KafkaUser
with user quotas
apiVersion: kafka.strimzi.io/v1beta1 kind: KafkaUser metadata: name: my-user labels: strimzi.io/cluster: my-cluster spec: # ... quotas: producerByteRate: 1048576 1 consumerByteRate: 2097152 2 requestPercentage: 55 3
For more information on these properties, see the KafkaUserQuotas
schema reference
6.2. Configuring a Kafka user
Use the properties of the KafkaUser
resource to configure a Kafka user.
You can use oc apply
to create or modify users, and oc delete
to delete existing users.
For example:
-
oc apply -f <user-config-file>
-
oc delete KafkaUser <user-name>
When you configure the KafkaUser
authentication and authorization mechanisms, ensure they match the equivalent Kafka
configuration:
-
KafkaUser.spec.authentication
matchesKafka.spec.kafka.listeners.*.authentication
-
KafkaUser.spec.authorization
matchesKafka.spec.kafka.authorization
This procedure shows how a user is created with TLS authentication. You can also create a user with SCRAM-SHA authentication.
The authentication required depends on the type of authentication configured for the Kafka broker listener.
Authentication between Kafka users and Kafka brokers depends on the authentication settings for each. For example, it is not possible to authenticate a user with TLS if it is not also enabled in the Kafka configuration.
Prerequisites
- A running Kafka cluster configured with a Kafka broker listener using TLS authentication and encryption.
- A running User Operator (typically deployed with the Entity Operator).
If you are using SCRAM-SHA authentication, you need a running Kafka cluster configured with a Kafka broker listener using SCRAM-SHA authentication.
Procedure
Prepare a YAML file containing the
KafkaUser
to be created.An example
KafkaUser
apiVersion: kafka.strimzi.io/v1beta1 kind: KafkaUser metadata: name: my-user labels: strimzi.io/cluster: my-cluster spec: authentication: 1 type: tls authorization: type: simple 2 acls: - resource: type: topic name: my-topic patternType: literal operation: Read - resource: type: topic name: my-topic patternType: literal operation: Describe - resource: type: group name: my-group patternType: literal operation: Read
Create the
KafkaUser
resource in OpenShift.oc apply -f <user-config-file>
-
Use the credentials from the
my-user
secret in your client application.