Status: this is a design draft created by Maël Valais mael@vls.dev on 24 January 2022 and updated on 27 July 2022. A consensus around "solution 1" was reached during the biweekly meeting on 27 July 2022. In September 2022, this page will be adapted to fit the cert-manager proposal template and then copied over to the design/ folder. Issues: Make it possible to use a projected service account token to the Vault Issuer instead of a service account Secret which is implemented in The Vault issuer can now be given a serviceAccountRef (PR 5502). Vault Service Account auth via ambient credentials which is implemented in Add possibility to use ambient credentials for login to vault. Affected users: Neil Witts (Morgan Stanley)
1/24/2023The problem: When enrolling a new certificate, for example by running vcert enroll or when using cert-manager, people get "stuck" with an error of the like: 500 Certificate \VED\Policy\Test\foo.com has encountered an error while processing, Status: This certificate cannot be processed while it is in an error state. Fix any errors, and then click Retry., Stage: 700. This message occurs when a past enrollment has failed or an enrollment was still in progress for that certificate. The current workaround is to call to POST /reset with Restart=False, and then re-run the command vcert enroll (or renew the certificate in cert-manager). We decided Solutions considered
1/24/2023⚠️ WARNING: ⚠️ this document is mostly wrong. I mixed up the paramater audiences= with the correct audience=. Since Vault doesn't validate parameters (at least not in the Kubernetes plugin), I didn't realize that audiences= was ignored entirely. Thanks to Tom Proctor for finding this out (comment). tl;dr: Vault 1.12 and below have a bug that prevents checking the JWT audience. The issue is documented in vault-plugin-auth-kubernetes#175. If you configure a Kubernetes auth role with the parameter audience set to vault, that parameter won't do anything. Any audience will be accepted by the role: vault write auth/kubernetes/role/cert-manager \ bound_service_account_names=vault \ bound_service_account_namespaces=cert-manager \ audience=vault # <-- ignored 🔥 Context: as part of The Vault issuer can now be given a serviceAccountRef (PR 5502), I had a doubt: does Vault verify the audience (aud value in the JWT) when using the Kubernetes auth method?
1/4/2023I thought it was possible to use a token without any role to perform the TokenReview call to the Kubernetes API server. But no: for the TokenReview call, the service account associated to the token used to authenticate (i.e., the Ahtorization: Bearer token HTTP header) must have the role system:auth-delegator. On the other side, the token within the TokenReview doesn't need to have any role attached. First, let us create a token with no role attached: token=$(kubectl create --raw /api/v1/namespaces/default/serviceaccounts/default/token -f- <<EOF | jq -r '.status.token' {
12/13/2022