Introduce the support for specifying a CA bundle in the helm chart #24862
Conversation
giorio94
added
kind/enhancement
giorio94
force-pushed
the
mio/ca-bundle-support
branch
from
041f69e
to
81f766d
Compare
|
ConformanceK8sKind hit unrelated flake: #24863 |
| # -- Configure the CA trust bundle used for the validation of the certificates | ||
| # leveraged by hubble and clustermesh. When enabled, it overrides the content of the | ||
| # 'ca.crt' field of the respective certificates, allowing for CA rotation with no down-time. | ||
| caBundle: |
There was a problem hiding this comment.
Could this be part of the ca field above instead? I understand the above is for a CA key pair but these do have some overlap. Not sure how it should look though.
There was a problem hiding this comment.
I had the same doubt when adding this field. Personally, I feel it is a bit better to keep them disjoint to highlight that they are not strictly related, since you might want to specify the bundle but not the CA info (e.g., when using cert-manager). I don't have a strong opinion though.
There was a problem hiding this comment.
Yeah, I don't feel too strongly, but I worry having two different sections might be confusing. Not sure.
There was a problem hiding this comment.
what happens when both ca and caBundle are specified?
There was a problem hiding this comment.
These two fields are independent. Essentially, ca is used to specify the CA for certificate generation through helm or the cronJob, while the caBundle, if set, overrides the ca.crt entry part of the certificate secret (which would be ca.tls if generated through helm/cronJob, but may be different), and it represents the set of trusted root certificates for the different cilium components. It mainly enables seamless CA rotation, since you can specify multiple trusted certificates at the same time.
For instance, you would configure caBundle only when relying on cert-manager to generate the certificates, ca only if you are only interested in certificate generation through helm/cronJob, or both in case you want both certificate generation and the support for CA rotation with no downtime.
|
/test |
This commit adds a note to the helm chart to clarify that the CA configuration does not take effect when using cert-manager to generate the certificates. Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>
This commit extends the helm chart to introduce the support for the specification of a CA trust bundle used for the validation of the certificates leveraged by hubble and clustermesh. If enabled, it overrides the content of the `ca.crt` field of the respective certificates, allowing for CA rotation with no down-time. The bundle can be either provided out-of-band, or created through Helm. Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>
giorio94
force-pushed
the
mio/ca-bundle-support
branch
from
81f766d
to
d9129fa
Compare
|
Rebased onto main to fix test failures due to mismatches between code and workflows. |
|
/test |
maintainer-s-little-helper
bot
added
the
ready-to-merge
|
/test Rerunning the tests, since the required list changed in the meanwhile. |
|
/ci-datapath A few matrix entries failed while creating the LVH VMs. Rerunning |
giorio94
removed
the
ready-to-merge
maintainer-s-little-helper
bot
added
the
ready-to-merge
I'd be good to point to the flake issues or to create them in such cases. Otherwise it's hard for the CI Health person to learn about these. |
Does it make sense to create an issue also for things like temporary |
This PR extends the helm chart to introduce the support for the specification of a CA trust bundle used for the validation of the certificates leveraged by hubble and clustermesh. If enabled, it overrides the content of the
ca.crtfield of the respective certificates, allowing for CA rotation with no down-time. The bundle can be either provided out-of-band, or created through Helm.