// Module included in the following assemblies:
//
// assembly-securing-kafka-clients.adoc

[id='con-securing-client-authorization-{context}']
= 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.

To use simple authorization, you set the `type` property to `simple` in `KafkaUser.spec.authorization`.
The simple authorization will use the Kafka Admin API to manage the ACL rules inside your Kafka cluster.
Whether ACL management in the User Operator is enabled or not depends on your authorization configuration in the Kafka cluster.

* For simple authorization, ACL management is always enabled.
* For OPA authorization, ACL management is always disabled.
  Authorization rules are configured in the OPA server.
* For Keycloak authorization, you can manage the ACL rules directly in Keycloak.
  You can also delegate authorization to the simple authorizer as a fallback option in the configuration.
  When delegation to the simple authorizer is enabled, the User Operator will enable management of ACL rules as well.
* For custom authorization using a custom authorization plugin, use the `supportsAdminApi` property in the `.spec.kafka.authorization` configuration of the `Kafka` custom resource to enable or disable the support.

If ACL managment is not enabled, Strimzi rejects a resource if it contains any ACL rules.

If you're using a standalone deployment of the User Operator, ACL management is enabled by default.
You can disable it using the `STRIMZI_ACLS_ADMIN_API_SUPPORTED` environment variable.

If no authorization is specified, the User Operator does not provision any access rights for the user.
Whether such a `KafkaUser` can still access resources depends on the authorizer being used.
For example, for the `AclAuthorizer` this is determined by its `allow.everyone.if.no.acl.found` configuration.

== ACL rules

`AclAuthorizer` uses ACL rules to manage access to Kafka brokers.

ACL rules grant access rights to the user, which you specify in the `acls` property.

For more information about the `AclRule` object, see the xref:type-AclRule-reference[`AclRule` schema reference].

== 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 in `KafkaUser`.

For more information on configuring super user access to brokers, see xref:con-securing-kafka-authorization-{context}[Kafka authorization].

== User quotas

You can configure the `spec` for the `KafkaUser` resource to enforce quotas so that a user does not exceed a configured level of access to Kafka brokers.
You can set size-based network usage and time-based CPU utilization thresholds.
You can also add a partition mutation quota to control the rate at which requests to change partitions are accepted for user requests.

.An example `KafkaUser` with user quotas
[source,yaml,subs="attributes+"]
----
apiVersion: {KafkaUserApiVersion}
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster
spec:
  # ...
  quotas:
    producerByteRate: 1048576 <1>
    consumerByteRate: 2097152 <2>
    requestPercentage: 55 <3>
    controllerMutationRate: 10 <4>
----
<1> Byte-per-second quota on the amount of data the user can push to a Kafka broker
<2> Byte-per-second quota on the amount of data the user can fetch from a Kafka broker
<3> CPU utilization limit as a percentage of time for a client group
<4> Number of concurrent partition creation and deletion operations (mutations) allowed per second

For more information on these properties, see the xref:type-KafkaUserQuotas-reference[`KafkaUserQuotas` schema reference].
