Deploy on Kubernetes #2
Conversation
| - name: SECRETHUB_CREDENTIAL | ||
| valueFrom: | ||
| secretKeyRef: | ||
| name: secrethub-mutating-webhook | ||
| key: secrethub_credential |
There was a problem hiding this comment.
This can be replaced with native authentication in the case of AWS EKS and soon also with native authentication on GKE.
| name: secrethub-mutating-webhook | ||
| namespace: default | ||
| path: "/" | ||
| caBundle: "${CA_BUNDLE}" |
There was a problem hiding this comment.
This should be replaced with the CA bundle of your cluster, which can be obtained with kubectl config view --raw --minify --flatten -o jsonpath='{.clusters[].cluster.certificate-authority-data}'
| spec: | ||
| containers: | ||
| - name: secrethub-mutating-webhook | ||
| image: simonbarendse/kubernetes-mutating-webhook:latest |
There was a problem hiding this comment.
This is the image resulting from the Dockerfile in this repo. If we agree with the current state, let's push that to the secrethub org on DockerHub:
| image: simonbarendse/kubernetes-mutating-webhook:latest | |
| image: secrethub/kubernetes-mutating-webhook:latest |
| - /bin/sh | ||
| - -c | ||
| args: | ||
| - "secrethub read kubernetes-webhook/webhook/cert.pem -o /webhook-certs/cert.pem && secrethub read kubernetes-webhook/webhook/key.pem -o /webhook-certs/key.pem" |
There was a problem hiding this comment.
How can other people deploy this if it uses kubernetes-webhook/webhook/cert.pem?
There was a problem hiding this comment.
Good spot! This should be variable, just like the ${CA_BUNDLE}. It's differs between different users/deployments.
| - /bin/sh | ||
| - -c | ||
| args: | ||
| - "secrethub read kubernetes-webhook/webhook/cert.pem -o /webhook-certs/cert.pem && secrethub read kubernetes-webhook/webhook/key.pem -o /webhook-certs/key.pem" |
There was a problem hiding this comment.
Is there a reason for storing these on SecretHub at all? Can't we just generate the key locally and then send a CSR to the k8s CA?
|
I'm closing this PR as we're currently focusing our efforts on AWS EKS and GKE. When we pick this up again, we should consider what's the circular dependency of deploying this as a pod in the same Kubernetes cluster as it applies to. For example, how do we ensure we can scale this deployment with another container when the webhook isn't availabe? |
This continues on the work of #1 and makes it possible to deploy the webhook on the Kubernetes cluster itself instead of to a cloud function.