ContainerImage.Pinniped/test
Ryan Richard a2ecd05240 Impersonator config controller writes CA cert & key to different Secret
- The CA cert will end up in the end user's kubeconfig on their client
  machine, so if it changes they would need to fetch the new one and
  update their kubeconfig. Therefore, we should avoid changing it as
  much as possible.
- Now the controller writes the CA to a different Secret. It writes both
  the cert and the key so it can reuse them to create more TLS
  certificates in the future.
- For now, it only needs to make more TLS certificates if the old
  TLS cert Secret gets deleted or updated to be invalid. This allows
  for manual rotation of the TLS certs by simply deleting the Secret.
  In the future, we may want to implement some kind of auto rotation.
- For now, rotation of both the CA and TLS certs will also happen if
  you manually delete the CA Secret. However, this would cause the end
  users to immediately need to get the new CA into their kubeconfig,
  so this is not as elegant as a normal rotation flow where you would
  have a window of time where you have more than one CA.
2021-03-01 17:02:08 -08:00
..
cluster_capabilities Introduce clusterhost package to determine whether a cluster has control plane nodes 2021-02-09 11:16:01 -08:00
deploy/dex Upgrade Debian base images from 10.7 to 10.8. 2021-02-10 15:57:16 -06:00
integration Impersonator config controller writes CA cert & key to different Secret 2021-03-01 17:02:08 -08:00
library concierge_impersonation_proxy_test.go: Make it work on more clusters 2021-02-25 14:40:18 -08:00