Strimzi
OSCP Support / Cluster CA #7539
Replies: 4 comments 9 replies
-
|
It depends on what exactly you want to do which is not completely clear as you seem to be mixing the server and client certificates. In general, you can provide your own CA -> that is covered by the docs, so you should be able to find the details there. |
Beta Was this translation helpful? Give feedback.
-
|
No worries. Yeh I did try supplying a ejbca generated certificate with signing capabilities but it’s getting stuck bringing up the zookeeper pod with No CA found. Same as this issue #4004 I’ll dig a bit deeper and make sure my cert is being added correctly. Is there a way to debug the zookeeper container and inspect the cert files getting added to zookeeper? Because it stops right away I can’t check out the file system on the container |
Beta Was this translation helpful? Give feedback.
-
|
Well, the |
Beta Was this translation helpful? Give feedback.
-
|
It turns out I didn't have CA flag set in X509v3 extensions. Once I fixed that, I get passed zookeeper bringup. But the problem is now that my CA does not know about the certificates that Strimzi is managing, it can not give an OCSP response for those certificates and Kafka fails to come up. Note the error below when attempting to OCSP verify the cert "CERTIFICATE_UNKNOWN" Which means that we cannot use certificates not generated by our CA. You mentioned that it's possible but not documented? Are you able to provide more info on this as I have no other choice but to generate the certificates in the cluster using my CA as Kakfa does not directly support OSCP, it must be configured directly in Java and therefore will apply to all TLS communications. Or as a separate option, maybe I could customize the script that generates the certificates and generate them on my CA instead? The operator script could generate a CSR and submit it to the EJBCA API in order to receive the signed cert. |
Beta Was this translation helpful? Give feedback.
-
|
Or is there an option to disable TLS inside the cluster altogether? And just enable TLS for the external listener? My inter node communication is all on a private network anyway |
Beta Was this translation helpful? Give feedback.
-
No, that is currently not possible. But if you think that you don't need TLS for the internal communication at all, why do you both with OSCP for the same?
There is no script generating certificates. It is part of the operator code. There is a work in progress proposal to make it more pluggable and configurable. But if you read it, it is not completely trivial to handle this.
Well, it is maybe possible and it really depends a lot on what your expectations are.
|
Beta Was this translation helpful? Give feedback.
-
|
“But if you think that you don't need TLS for the internal communication at
all, why do you both with OSCP for the same?”
Like I said, Kafka does not support OCSP, so it must be enabled at the Java
level. Therefore I cannot distinguish between external and internal TLS. If
I could turn off internal TLS, then my problem is solved. I cannot turn off
OCSP for internal traffic though if I need it for external. It’s either all
or all off.
…On Sun, Oct 30, 2022 at 5:53 AM Jakub Scholz ***@***.***> wrote:
Or is there an option to disable TLS inside the cluster altogether? And
just enable TLS for the external listener? My inter node communication is
all on a private network anyway
No, that is currently not possible. But if you think that you don't need
TLS for the internal communication at all, why do you both with OSCP for
the same?
Or as a separate option, maybe I could customize the script that generates
the certificates and generate them on my CA instead? The operator script
could generate a CSR and submit it to the EJBCA API in order to receive the
signed cert.
Are the cert generation scripts all here:
https://github.com/strimzi/strimzi-kafka-operator/tree/main/docker-images/kafka-based/kafka/scripts
?
There is no script generating certificates. It is part of the operator
code. There is a work in progress proposal
<strimzi/proposals#46> to make it more pluggable
and configurable. But if you read it, it is not completely trivial to
handle this.
You mentioned that it's possible but not documented? Are you able to
provide more info on this as I have no other choice but to generate the
certificates in the cluster using my CA as Kakfa does not directly support
OSCP, it must be configured directly in Java and therefore will apply to
all TLS communications.
Well, it is *maybe* possible and it really depends a lot on what your
expectations are.
- The server certificates are stored in Secrets. The documented and
working way is that you prepare the secret with the CA to use your own CA
and Strimzi generates the certificates. In general, you can prepare all the
secrets with the server certificates as well. But it is more complicated as
you need to make sure they have the proper common names, SANs etc. to make
this work.
- Setting it up should be still the easy part as you can copy the CNs
and the SANs from an existing cluster using the Strimzi CA. But the next
issue would be a renewal where you need to roll out the new certificates
and CAs which is not simple today manually. You would probably need to roll
the pods manually etc.
—
Reply to this email directly, view it on GitHub
<#7539 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDTDHTVDO5HAVLYHDFHUIDWFZOTRANCNFSM6AAAAAARQWPV5Q>
.
You are receiving this because you authored the thread.Message ID:
<strimzi/strimzi-kafka-operator/repo-discussions/7539/comments/4011945@
github.com>
|
Beta Was this translation helpful? Give feedback.
-
Maybe I misunderstand what do you mean. But there is no internal or external TLS. The TLS is always done by Kafka using Java libraries for it. Do you mean with internal and external TLS the TLS on internal and external Kafka listeners? I.e. within the Kube cluster and outside the Kube cluster? Or what do you mean with it? |
Beta Was this translation helpful? Give feedback.
-
|
Yeh exactly, when I say internal TLS I mean within the cluster.
When I say external I mean to my clients at the edge connecting over the
internet. I only need TLS on the external listener where the edge clients
connect.
…On Sun, Oct 30, 2022 at 8:51 AM Jakub Scholz ***@***.***> wrote:
Like I said, Kafka does not support OCSP, so it must be enabled at the Java
level. Therefore I cannot distinguish between external and internal TLS. If
I could turn off internal TLS, then my problem is solved. I cannot turn off
OCSP for internal traffic though if I need it for external. It’s either all
or all off.
Maybe I misunderstand what do you mean. But there is no internal or
external TLS. The TLS is always done by Kafka using Java libraries for it.
Do you mean with *internal* and *external* TLS the TLS on internal and
external Kafka listeners? I.e. within the Kube cluster and outside the Kube
cluster? Or what do you mean with it?
—
Reply to this email directly, view it on GitHub
<#7539 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDTDHR2SHIMPDOJA6XTJ23WF2DOZANCNFSM6AAAAAARQWPV5Q>
.
You are receiving this because you authored the thread.Message ID:
<strimzi/strimzi-kafka-operator/repo-discussions/7539/comments/4012655@
github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
So, there are 3 different parts:
Now, for 1), the Strimzi CA is used and normally, Strimzi uses it to issue the server certificates. For 2+3), by default the Strimzi CA and certificates issues by it are what is used (if you enabled the TLS encryption in the first place). But you can configure your own listener certificate. Which is just a server certificate which is used for given particular listener. You issue it whatever way you want - so you can configure your own rules for it. Not sure if this helps in your particular use-case. But these are the different levels of TLS in Strimzi. The custom Cluster CA is not always what users want or what they can customize. But often there are happy with the custom listener certs which are easier to configure and simply leave the 1) part to Strimzi. The Clients CA stands on a side of these -> this is what is used for TLS client authentication / mTLS and is completely separate from the server certificates described above. |
Beta Was this translation helpful? Give feedback.
-
|
Yeh no worries. The problem for me is that only certificates signed by my
external CA can be used due to the OCSP requirement. Looks like I’ll need
to build the cluster manually without the operator. Thanks anyway. Cheers
…On Sun, Oct 30, 2022 at 11:40 AM Jakub Scholz ***@***.***> wrote:
So, there are 3 different parts:
1. Internal as in really internal => includes the replication and
other communication between the Kafka nodes, ZooKeeper communication,
communication between Zoo and Kafka etc. This is always TLS. This is the
most complicated part as you have multiple layers (Zoo + Kafka + operators)
which you need to link and secure which makes the roll out and things such
as renewals hard. This is also where particular CNs or SANs are needed most
as not having them breaks your cluster.
2. Internal communication as in the type: internal listeners -> this
means communication between clients running in the same Kube cluster and
the Kafka brokers. Here, you can enable or disable TLS according to your
needs.
3. External communication meaning the listeners which expose the Kafka
cluster outside of your Kube cluster. Here, it depends on the exact type.
Routes and Ingress requires TLS encryption to be enabled because of
internal Route and Ingress workings. For node ports or load balancers, you
can enable or disable TLS as you want.
Now, for 1), the Strimzi CA is used and normally, Strimzi uses it to issue
the server certificates. For 2+3), by default the Strimzi CA and
certificates issues by it are what is used (if you enabled the TLS
encryption in the first place). But you can configure your own *listener
certificate*. Which is just a server certificate which is used for given
particular listener. You issue it whatever way you want - so you can
configure your own rules for it.
Not sure if this helps in your particular use-case. But these are the
different levels of TLS in Strimzi. The custom Cluster CA is not always
what users want or what they can customize. But often there are happy with
the custom listener certs which are easier to configure and simply leave
the 1) part to Strimzi.
------------------------------
The Clients CA stands on a side of these -> this is what is used for TLS
client authentication / mTLS and is completely separate from the server
certificates described above.
—
Reply to this email directly, view it on GitHub
<#7539 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDTDHXH3VMN2YOCAN3VH4TWF2XJDANCNFSM6AAAAAARQWPV5Q>
.
You are receiving this because you authored the thread.Message ID:
<strimzi/strimzi-kafka-operator/repo-discussions/7539/comments/4013285@
github.com>
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Apparently Kafka does not directly support OCSP verification, but it can be added directly to java using java.security properties.
I'm currently generating my own client certs in EJBCA, and need Kafka to reject any connections from revoked clients.
The problem for me is that I was using the default CA certs in Strimzi but these will no longer work as they won't be validated in my OCSP responder.
Is it possible to externally provide all the Strimzi Cluster certs and turn off the Strimzi cert generation altogether?
Or is the only option to provide an intermediate CA key/cert to Strimzi to get this to work?
Beta Was this translation helpful? Give feedback.
All reactions