This project provides a Kubernetes operator to help applications bind to an Apache Kafka® cluster that is managed by the Strimzi cluster operator.
The operator creates a single Kubernetes Secret
resource containing all the connection details for the Kafka cluster. This removes the need for applications to query multiple Kubernetes resources to get connection information. The Secret
follows the conventions laid out in the Service Binding Specification for Kubernetes v1.0.0.
The operator is built using the Java Operator SDK.
Running the Access OperatorThe latest release of the Access Operator can be deployed using the manifests in the install
directory. The dev guide describes how to build and run the Access Operator from source.
For the operator to start successfully, you need the Strimzi Kafka
and KafkaUser
custom resource definitions installed in your Kubernetes cluster. You can get these from the Strimzi GitHub repository, or use the Strimzi quickstart guide to also deploy the Strimzi cluster operator and a Kafka instance at the same time.
To deploy the Access Operator in the strimzi-access-operator
namespace:
The command deploys the Strimzi Access Operator on the Kubernetes cluster.
Removing the Access OperatorTo delete the strimzi-access-operator
deployment:
kubectl delete -f install
This command removes all Kubernetes components associated with the Strimzi Access Operator and deletes the deployment.
Using the Access OperatorTo make use of the Access Operator, create a KafkaAccess
custom resource (CR). You must specify the name of the Kafka
CR you want to connect to. You can optionally also specify the name of the listener in the Kafka
CR and a KafkaUser
. See the examples folder for some valid KafkaAccess
specifications.
If you do not specify which listener you want to connect to, the operator uses the following rules to choose a listener:
Kafka
CR, that listener is chosen.Kafka
CR, the operator filters the list by comparing the tls
and authentication
properties in the Kafka
and KafkaUser
CRs to select a listener with the appropriate security.internal
.Once the Access Operator has created the binding Secret
, it updates the KafkaAccess
custom resource to put the name of the secret in the status, for example:
... status: binding: name: kafka-binding
The Secret
created by the Access Operator has the following structure:
apiVersion: v1 kind: Secret metadata: name: kafka-binding type: servicebinding.io/kafka data: type: kafka provider: strimzi bootstrap.servers: # comma separated list of host:port for Kafka bootstrap-servers: # comma separated list of host:port for Kafka bootstrapServers: # comma separated list of host:port for Kafka security.protocol: # one of PLAINTEXT, SASL_PLAINTEXT, SASL_SSL or SSL securityProtocol: # one of PLAINTEXT, SASL_PLAINTEXT, SASL_SSL or SSL # Provided if TLS enabled: ssl.truststore.crt: # Strimzi cluster CA certificate # Provided if selected user is SCRAM auth: username: # SCRAM username password: # SCRAM password sasl.jaas.config: # sasl jaas config string for use by Java applications sasl.mechanism: SCRAM-SHA-512 saslMechanism: SCRAM-SHA-512 # Provided if selected user is mTLS: ssl.keystore.crt: # certificate for the consuming client signed by the clients' CA ssl.keystore.key: # private key for the consuming client
Developers can make this Secret
available to their applications themselves, or use an operator that implements the Service Binding specification to do it.
If you encounter any issues while using the Access Operator, you can get help through the following methods:
You can contribute by:
All bugs, tasks or enhancements are tracked as GitHub issues.
The dev guide describes how to build the operator and how to test your changes before submitting a patch or opening a PR.
If you want to get in touch with us first before contributing, you can use:
Learn more on how you can contribute on our Join Us page.
Strimzi Access Operator is licensed under the Apache License, Version 2.0
Strimzi Access Operator containers are signed using the cosign
tool. Strimzi currently does not use the keyless signing and the transparency log. To verify the authenticity of the container, you can copy the following Strimzi public key into a file:
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAET3OleLR7h0JqatY2KkECXhA9ZAkC
TRnbE23Wb5AzJPnpevvQ1QUEQQ5h/I4GobB7/jkGfqYkt6Ct5WOU2cc6HQ==
-----END PUBLIC KEY-----
Use the following cosign
command to verify the signature:
cosign verify --key strimzi.pub quay.io/strimzi/kafka-access-operator:latest --insecure-ignore-tlog=true
Software Bill of Materials (SBOM)
Strimzi Access Operator publishes the software bill of materials (SBOM) of our containers. The SBOMs are published as archives with SPDX-JSON
and Syft-Table
formats, and they are signed using cosign. For releases, they are also pushed into the container registry. To verify the authenticity of the SBOM signatures, use the Strimzi public key:
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAET3OleLR7h0JqatY2KkECXhA9ZAkC
TRnbE23Wb5AzJPnpevvQ1QUEQQ5h/I4GobB7/jkGfqYkt6Ct5WOU2cc6HQ==
-----END PUBLIC KEY-----
Use the following cosign
command to verify the signatures:
cosign verify-blob --key cosign.pub --bundle <SBOM-file>.bundle --insecure-ignore-tlog=true <SBOM-file>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4