proofpoint / certificate-init-container Goto Github PK

Links

• https://kubernetes.io/docs/setup/release/notes/#kube-apiserver
  • https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/

TL;DR - practically speaking this corresponds with rbac permissions for the automatic approver

Corresponding kapprover issue: #30.

Getting this error since we upgrade our GKE to use k8s 1.21.
It will be great if you can bump the v1beta1 to the new k8s api entrypoint.

Right now, CN is hardcoded to be the ip-FQDN of the pod, but for some PKI use cases it makes more sense for this to have other values.
For Searchguard you need to match the node certificate principal with a regex, so the CN needs to be predictable and only cover the nodes themselves. We have solved this by having a flag that sets the headless service DNS name to be set as CN, but it could be more flexible to just allow user input for CN value.

Some of the key/cert pairs we want to issue, we want to make sure are only used for client certificate authentication, so it would be cool if there was a way to customise the key usages requested on the CSR.

We want to send more information on the certificate than just CN to indicate heritage of the key, mainly what helm-chart they belong to, but also to read up "roles" for authorization.

(edit: I hijacked this issue because I realised my previous task was already addressing the original subject)

Specifically get,list are needed for pods, services in the default API group when using these options:

- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get", "list"]

Consider adding this to the README.

kube apiserver logs:

Could not query pod "<pod>" in namespace "<namespace>": 
  pods "<pod>" is forbidden: 
  User "system:serviceaccount:kube-system:<name>" 
  cannot get resource "pods" in API group "" in the namespace "<namespace>"

Specifically kube api server expects admission control webhooks to a have SAN entry for <service-name>.kube-system.svc

...
initContainers:
...
    args:
      - -namespace=$(NAMESPACE)
      - -pod-name=$(POD_NAME)
      - -query-k8s
      - -include-unqualified
...

Results in an issued cert with the necessary SAN entry for the "un-qualified" <service-name>.kube-system.svc:

# kubectl -n kube-system logs deployment/<name>-webhook -c certificate-init-container
# openssl x509 -in certificate.crt -text -noout

Certificate Information:
Common Name: 100-96-2-2.kube-system.pod.cluster.local
Subject Alternative Names: 
  100-96-2-2.kube-system.pod.cluster.local
  <service-name>.kube-system.svc.cluster.local
  <service-name>.kube-system.svc
  IP Address:100.96.2.2
  IP Address:100.69.175.40
Valid From: August 14, 2020
Valid To: August 14, 2021
Serial Number: 8f618d0c4564d8233bc158d097534b03

Without -include-unqualified kube-apiserver will reject the created certificate:

Failed calling webhook, 
  failing open <name>: 
     failed calling webhook "<name>": 
     Post https://<service-name>.kube-system.svc:443/mutate?timeout=10s: x509: certificate is valid for 
       <service-name>.kube-system.svc.cluster.local, (fully qualified service name)
not <service-name>.kube-system.svc

The PKCS#8 format is widely supported (java and most applications implementing TLS through any library can use it). I think it is a good alternative to supporting keystore format for java support. It could be controlled by a flag and be output to the same filename as the original PKCS#1 key.
Could also support encryption of the key then, though that may be a bit redundant in an automated system (other than for compliance reasons).

Use case: We run a job to initialize an index for Searchguard in Elasticsearch that authenticates using a client certificate to our cluster. This requires an "admin" client certificate that has a DN that is matched on. We store this in a secret right now to allow users to use it to manually administer the Searchguard index, and then mount the secret in the main container. So there is no need to write it to disk.

For us specifically, there's no need for the manual workflow however, so if there's an automatic approver, we can use transient keys instead.

Not sure if this is the best place for this but I am using your container and it is working great! Thank you for that.

Currrently I have to manually approve the CSR (kubectl certificate approve ). I want my pipeline (jenkins) to automatically approve them as part of the deploy. Is there a recommended way to do this?