Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

updating label in KEP-3257 #4971

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
+4 −4
Open

updating label in KEP-3257 #4971

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions keps/sig-auth/3257-cluster-trust-bundles/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -290,7 +290,7 @@ kind: ClusterTrustBundle
metadata:
name: example.com:server-tls:foo
labels:
kubernetes.io/cluster-trust-bundle-version: live
k8s.example/cluster-trust-bundle-version: live
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: I'd suggest sticking with example.com as the label namespace, consistent with the signer name domain

Suggested change
k8s.example/cluster-trust-bundle-version: live
example.com/cluster-trust-bundle-version: live

spec:
signerName: example.com/server-tls
trustBundle: "<... PEM DATA ...>"
Expand Down Expand Up @@ -321,7 +321,7 @@ spec:
+ - clusterTrustBundle:
+ signerName: example.com/server-tls
+ labelSelector:
+ kubernetes.io/cluster-trust-bundle-version: live
+ k8s.example/cluster-trust-bundle-version: live
+ path: ca_certificates.pem
```

Expand Down Expand Up @@ -562,11 +562,11 @@ Human operators or controllers may use unique names and labels to maintain diffe

For example, if I maintain `example.com/my-signer`, I can use the following strategy:
* I maintain one ClusterTrustBundle named `example.com:my-signer:live`, labeled
`kubernetes.io/cluster-trust-bundle-version=live` (the object name is mostly
`k8s.example/cluster-trust-bundle-version=live` (the object name is mostly
irrelevant).
* I maintain an additional ClusterTrustBundle named
`example.com:my-signer:canary`, labeled
`kubernetes.io/cluster-trust-bundle-version=canary`.
`k8s.example/cluster-trust-bundle-version=canary`.
* I have coordinated some fraction of my workloads to use the canary label
selector, while the bulk of them use the live label selector
* When I want to perform a root rotation or other trust change, I edit the
Expand Down