-
Notifications
You must be signed in to change notification settings - Fork 95
Open
Description
The upstream ClusterTrustBundle resource is reaching beta in k8s 1.33 which gives us a great incentive to adopt the resource. It'll be usable as both a source and a target; this issue focuses on using it as a target.
Key Differences from Existing Targets
- ClusterTrustBundle only exposes a
trustBundlefield for PEM-encoded certs; there's no extra space for PKCS#12 or JKS, so CTB won't be able to support it. - Because of 1, the current layout of the Bundle CRD risks being confusing; AdditionalFormats looks like it applies to all targets, but ClusterTrustBundle won't be affected. Longer term this could inform how we want to evolve the CRD.
- ClusterTrustBundle includes a "signer" field, which users may want to be able to configure when creating the bundle. This needs further investigation to determine what the correct approach is.
- All service accounts can read CTBs by default, but we'll need permission to write
- CTBs are global-scoped and so don't need to be tracked across namespaces.
- CTBs are currently v1alpha1 and will migrate to v1beta1 and eventually v1. We'll need to handle that evolution which we didn't need to handle with ConfigMap / Secret.
- CTB targets may need to be manually enabled in trust-manager for k8s < 1.33
- CTBs impose requirements on naming based on whether they're signer linked or unlinked. We can't "just" use the trust-manager
Bundleresource's name.
Testing ClusterTrustBundle
The following KindConfig will enable the feature flag on k8s 1.28 - 1.32, where the feature is in Alpha:
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
featureGates:
ClusterTrustBundle: true
ClusterTrustBundleProjection: true
runtimeConfig:
"certificates.k8s.io/v1alpha1/clustertrustbundles": "true"farazkhawaja, ryan0x44 and cwegener
Metadata
Metadata
Assignees
Labels
No labels