The vault issuer can now be given a serviceAccountRef instead of relying on static service account tokens by maelvls · Pull Request #5502 · cert-manager/cert-manager

maelvls · 2022-10-11T09:15:30Z

Documentation: https://release-next--cert-manager-website.netlify.app/docs/configuration/vault/#authenticating-with-kubernetes-service-accounts
🌟 The solution that this PR implements Proposed solution: cert-manager requests a token using the Token Request API

tl;dr: With the new serviceAccountRef field available in cert-manager 1.12 and above, cert-manager doesn't requests the token on behalf of the pod in order to authenticate with Vault. Thanks to serviceAccountRef, the Vault issuer will stop relying on insecure static tokens, and use short-lived tokens instead.

apiVersion: cert-manager.io/v1
kind: Issuer
spec:
  vault:
    path: pki/sign/vault-issuer
    server: http://vault.default.svc.cluster.local:8200
    auth:
      kubernetes:
        role: vault-issuer
        mountPath: /v1/auth/kubernetes
        serviceAccount:
          name: vault-issuer     # ✨

The expiration duration and the audience aren't configurable by the user:

The audience is generated by cert-manager to prevent a malicious user from creating a second issuer with the intent of reusing the existing service account. The format is:

"vault://<namespace>/<issuer-name>"   (for an Issuer)
"vault://<issuer-name>"               (for a ClusterIssuer)

Note that this extra security isn't mandatory. You can very well configure the role with an empty audience. That said, we recommend that you use the audience field, e.g.:

vault write auth/kubernetes/role/vault-issuer \
    bound_service_account_names=vault-issuer \
    bound_service_account_namespaces=default \
    audience="vault://default/vault-issuer" \
    policies=vault-issuer \
    ttl=1m

Alternative solution considered: we considered using a hard-coded vault audience, but that did not allow to prevent the "Risk 1" (see below table). The UX would have been better, and would correspond to what people expect from an audience (i.e., the audience should be commanded by Vault to cert-manager, not the other way around). But since this is an extra level of security (extra because Vault won't check the audience by default), it should not affect the UX much.

Risk A	Risk B

Remediation: Restrict Issuer in Vault Role: Include the issuer name and namespace to the JWT and configure Vault to only accept that issuer name and namespace. For example, use `vault://namespace-1/issuer-1` as the audience. URL lock down: Using RBACs, make sure the Issuer and ClusterIssuer can only be edited by administrators. That should prevent the possibility of an actor using a URL pointing to a malicious server.	Remediation: Audience lock down: Use a hardcoded audience such as `vault`, or a hardcoded prefix such as `vault-`. Forbid sensitive audiences:* Refuse the cluster's audience like https://kubernetes.default.svc.cluster.local. URL lock down: Using RBACs, make sure the Issuer and ClusterIssuer can only be edited by administrators. That should prevent the possibility of an actor using a URL pointing to a malicious server. One SA per external service: Enforce that each service account is only ever linked to a single external service. E.g., one service account for Vault, one for GCP, one for AWS. Least privileges: Enforce that the service account attached to that JWT doesn't have any privileges.

The expiration duration for the Kubernetes tokens is hard-coded to 10 minutes (that's the minimum accepted). The expiration duration for the Vault tokens is 1 minute. The expiration duration is set to 10 minute because the Kubernetes token will be immediately discarded after authenticating with Vault. No token rotation is done; instead, a new Kubernetes token is requested on every call to Vault. We have discussed this multiple times, and it seems OK as a first iteration.
POSSIBLE BREAKING CHANGE: There is now webhook-side validation for the vault.auth field in the Issuer and ClusterIssuer. Previously, the validation was only performed "controller-side". People were able to create a faulty Issuer or ClusterIssuer, and they won't be able anymore. I made sure that the new validation is looser or equal to the existing controller-side validation so that Issuers and ClusterIssuers that were working previously are still working now.

Work

Unit test ("if kubernetes.serviceAccountRef set, request token and exchange it for a vault token"),

End-to-end test:

make e2e GINKGO_FOCUS=".*should be ready with a valid serviceAccountRef"`)

Documentation on the website (Vault: document the new field "serviceAccountRef" website#1081)
I manually tested the feature on these environments: kind cluster (Kubernetes 1.21) with an internal Vault running as a deployment.
Webhook-side validation (eg only one of [secretRef, serviceAccountRef] can be used).
Controller-side validation.

If you want to test this feature, here are the steps:

 make -j e2e-setup-certmanager
helm upgrade --install vault hashicorp/vault --set server.dev.enabled=true --set server.logLevel=debug --set global.tlsDisable=true --wait
kubectl wait --for=condition=Ready pod vault-0

kubectl exec vault-0 -i -- vault secrets enable pki
kubectl exec vault-0 -i -- vault secrets tune -max-lease-ttl=175200h pki
kubectl exec vault-0 -i -- vault write pki/root/generate/internal common_name=example.com key_type=ec key_bits=256 ttl=175200h
kubectl exec vault-0 -i -- vault write pki/config/urls \
    issuing_certificates="http://vault.default:8200/v1/pki/ca" \
    url_distribution_points="http://vault.default:8200/v1/pki/crl"
kubectl exec vault-0 -i -- vault write pki/roles/vault-issuer allowed_domains=cluster.local allow_subdomains=true max_ttl=48h key_type=ec key_bits=256

kubectl exec vault-0 -i -- vault auth enable kubernetes
kubectl exec vault-0 -i -- sh -c 'vault write auth/kubernetes/config \
   token_reviewer_jwt="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
   kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443" \
   kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
   issuer=https://kubernetes.default.svc.cluster.local'

kubectl exec vault-0 -i -- vault policy write vault-issuer - <<EOF
path "pki*"                 { capabilities = ["read", "list"] }
path "pki/roles/vault-issuer"   { capabilities = ["create", "update"] }
path "pki/sign/vault-issuer"    { capabilities = ["create", "update"] }
path "pki/issue/vault-issuer"   { capabilities = ["create"] }
EOF
kubectl exec vault-0 -i -- vault write auth/kubernetes/role/vault-issuer \
   bound_service_account_names=vault-issuer \
   bound_service_account_namespaces=default \
   audience=vault://default/vault-issuer \
   policies=vault-issuer \
   ttl=1m

Then, create an issuer and a certificate:

kubectl apply -f- <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: vault-issuer
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: vault-issuer
  namespace: default
rules:
  - apiGroups: ['']
    resources: ['serviceaccounts/token']
    resourceNames: ['vault-issuer']
    verbs: ['create']
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: vault-issuer
  namespace: default
subjects:
  - kind: ServiceAccount
    name: cert-manager
    namespace: cert-manager
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: vault-issuer
---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: vault-issuer
  namespace: default
spec:
  vault:
    path: pki/sign/vault-issuer
    server: http://vault.default.svc.cluster.local:8200
    auth:
      kubernetes:
        role: vault-issuer
        mountPath: /v1/auth/kubernetes
        serviceAccountRef:
          name: vault-issuer # ✨
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-com
spec:
  secretName: example-com-tls
  issuerRef:
    name: vault-issuer
  commonName: example.cluster.local
  dnsNames:
  - example.cluster.local
  privateKey:
    algorithm: ECDSA
EOF

If you want to run the new e2e locally:

make -j e2e-setup-certmanager e2e-setup-vault
make e2e GINKGO_FOCUS=".*should be ready with a valid serviceAccountRef"

/kind feature
/area vault

The Vault issuer can now be used with ephemeral Kubernetes tokens. With the new `serviceAccountRef` field, cert-manager generates a short-lived token associated to the service account to authenticate to Vault. Along with this new feature, we have added validation logic in the webhook in order to check the `vault.auth` field when creating an Issuer or ClusterIssuer. Previously, it was possible to create an Issuer or ClusterIssuer with an invalid value for `vault.auth`.

The main reason for bumping Vault's version is because 1.2.3 is not compatible with the config parameter `disable_iss_validation`, which is needed for accommodating the future tests [1] that rely on bound tokens and static tokens. For context, Vault 1.2.3 was released on Sep 9, 2019 [2] but `disable_iss_validation` was only added on July 21st, 2020 in Vault 1.5.0. Due to a breaking change that happened in Vault 1.5.0 [3] in which Vault started loading the pod's token instead of using the same token (to be reviewed) for authenticating. An alternative solution could have been to prevent the service account from being mounted to the pod, but I figured that having the two service accounts separated is a better practice. [1]: cert-manager#5502 [2]: hashicorp/vault@c14bd9a2 [3]: https://github.com/hashicorp/vault/blob/main/CHANGELOG.md#150 Signed-off-by: Maël Valais <mael@vls.dev>

maelvls · 2022-11-30T11:50:38Z

Update: last Friday, I worked on the end-to-end tests, and it now works! (cf. #5604) I also started the unit tests, but that will require another day of work. I'll plan another day of work soon.

The main reason for bumping Vault's version is because 1.2.3 is not compatible with the config parameter `disable_iss_validation`, which is needed for accommodating the future tests [1] that rely on bound tokens and static tokens. For context, Vault 1.2.3 was released on Sep 9, 2019 [2] but `disable_iss_validation` was only added on July 21st, 2020 in Vault 1.5.0. Due to a breaking change that happened in Vault 1.5.0 [3] in which Vault started loading the pod's token instead of using the same token (to be reviewed) for authenticating. An alternative solution could have been to prevent the service account from being mounted to the pod, but I figured that having the two service accounts separated is a better practice. [1]: cert-manager#5502 [2]: hashicorp/vault@c14bd9a2 [3]: https://github.com/hashicorp/vault/blob/main/CHANGELOG.md#150 Signed-off-by: Maël Valais <mael@vls.dev>

internal/vault/vault.go

I had mistakenly re-added this function in 76eef68. It had been removed in 6e05f43. Signed-off-by: Maël Valais <mael@vls.dev>

inteon

Thank you for all the work you put into this PR
/lgtm
/approve

Please unhold when you agree that this PR can be merged.
/hold

Documentation for this feature will be added here: cert-manager/website#1081

jetstack-bot · 2023-02-08T10:17:35Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: inteon, maelvls

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

~~OWNERS~~ [inteon,maelvls]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

maelvls · 2023-02-09T09:33:23Z

/unhold

maelvls · 2023-02-10T18:45:18Z

Udpate: We just released v1.12.0-alpha.0 with the serviceAccountRef feature! I am particularly eager to hear your feedback.

More specifically, I am unsure about the decision of using an "auto-generated" audience. The consequence is that you need to create one Vault role per Issuer. You can't re-use the same Issuer or ClusterIssuer for a given Vault role. For example, I'll have to create the following role for my Issuer vault-issuer that is located in the namespace sandbox:

vault write auth/kubernetes/role/vault-issuer \
    bound_service_account_names=vault-issuer-sa \
    bound_service_account_namespaces=sandbox \
    audience="vault://sandbox/vault-issuer" \
    policies=vault-issuer

I cannot re-use this one Vault role with multiple Issuers or ClusterIssuers. If I have another team that needs a different ClusterIssuer, I will have to create another Vault role.

My assumption is that people will default to not using any audience (which means less security) so that they can re-use the same service account and Vault role in multiple Issuers or ClusterIssuers. For example, the following role omits audience, which means that Vault won't check the audience, which means the same Vault role can be used in multiple Issuers or ClusterIssuers:

vault write auth/kubernetes/role/vault-issuer \
    bound_service_account_names=team-1-sa \
    bound_service_account_namespaces=sandbox \
    policies=vault-issuer

If most people was to do this, it might be preferable that we switch to a hardcoded audience such as audience=vault.

TheFutonEng · 2023-02-21T14:30:06Z

@maelvls , without this feature, are users required to deploy both Vault and Cert-Manager in the default namespace together? Is there a supported posture where they can be in their own namespaces? I've been trying separate namespaces for a while without success and the crux of the issue I am running into seems to be the ClusterIssuer is unable to read the service account token (there's no place in the ClusterIssuer definition to declare the namespace where the token lives).

maelvls · 2023-03-10T10:06:06Z

Without this feature, are users required to deploy both Vault and cert-Manager in the default namespace together? [...] ClusterIssuer is unable to read the service account token.

You are correct, there is no way to specify the "service account lookup namespace" used for Vault in a ClusterIssuer. The "service account lookup namespace" is conflated with the "namespace in which resources get created" and grouped under the global flag --cluster-resource-namespace. That's a bit unfortunate, I agree 😬

paulcostinean · 2023-04-03T15:02:01Z

The generated audience claim in the token works really well for a deployment with multiple issuers and separate roles. The hardcoded one could be added in case people want to share the same vault role. Both sound sensible. jwt supports an array in the audience claim.

A small nit about this PR: I found that cert-manager needs a create permission on serviceaccounts/token for this to work (in the namespace cert-manager is deployed in)

Garagoth · 2023-06-07T21:04:09Z

I am having issues with audience in JWT - more details in #6150
Basically kube-api complains that "vault://vault-issuer" is not a proper audience and rejects authentication.

This PR contains the following updates: | Package | Update | Change | |---|---|---| | [cert-manager](https://github.com/cert-manager/cert-manager) | minor | `v1.8.2` -> `v1.12.3` | --- ### Release Notes <details> <summary>cert-manager/cert-manager (cert-manager)</summary> ### [`v1.12.3`](https://github.com/cert-manager/cert-manager/releases/tag/v1.12.3) [Compare Source](https://github.com/cert-manager/cert-manager/compare/v1.12.2...v1.12.3) #### Changes by Kind ##### Bugfixes - BUGFIX\[cainjector]: 1-character bug was causing invalid log messages and a memory leak ([#6235](https://github.com/cert-manager/cert-manager/issues/6235), [@jetstack-bot](https://github.com/jetstack-bot)) ### [`v1.12.2`](https://github.com/cert-manager/cert-manager/releases/tag/v1.12.2) [Compare Source](https://github.com/cert-manager/cert-manager/compare/v1.12.1...v1.12.2) #### Known issues - cainjector contains a memory leak due to re-assignment of a log variable (see https://github.com/cert-manager/cert-manager/issues/6217). The fix will be released in v1.12.3. See https://github.com/cert-manager/cert-manager/pull/6232 for context. #### Changes by Kind ##### Bugfixes - BUGFIX: `cmctl check api --wait 0` exited without output; we now make sure we perform the API check at least once ([#6116](https://github.com/cert-manager/cert-manager/issues/6116), [@jetstack-bot](https://github.com/jetstack-bot)) ### [`v1.12.1`](https://github.com/cert-manager/cert-manager/releases/tag/v1.12.1) [Compare Source](https://github.com/cert-manager/cert-manager/compare/v1.12.0...v1.12.1) ### v1.12.1 This release contains a couple dependency bumps and changes to ACME external webhook library. #### Known issues - [`cmctl` API check](https://cert-manager.io/docs/installation/verify/) is broken in v1.12.1. We suggest that you do not upgrade `cmctl` to this version. The fix will be released in v1.12.2. See [#6116](https://github.com/cert-manager/cert-manager/issues/6116) for context. - cainjector contains a memory leak due to re-assignment of a log variable (see https://github.com/cert-manager/cert-manager/issues/6217). The fix will be released in v1.12.3. See https://github.com/cert-manager/cert-manager/pull/6232 for context. #### Changes by Kind ##### Other (Cleanup or Flake) - Don't run API Priority and Fairness controller in webhook's extension apiserver ([#6085](https://github.com/cert-manager/cert-manager/pull/6085), [@irbekrm](https://github.com/irbekrm)) - Adds a warning for folks to not use controller feature gates helm value to configure webhook feature gates ([#6100](https://github.com/cert-manager/cert-manager/pull/6100), [@irbekrm](https://github.com/irbekrm)) ##### Uncategorized - Updates Kubernetes libraries to `v0.27.2`. ([#6077](https://github.com/cert-manager/cert-manager/pull/6077), [@lucacome](https://github.com/lucacome)) - Updates controller-runtime to `v0.15.0` ([#6098](https://github.com/cert-manager/cert-manager/pull/6098), [@lucacome](https://github.com/lucacome)) ### [`v1.12.0`](https://github.com/cert-manager/cert-manager/releases/tag/v1.12.0) [Compare Source](https://github.com/cert-manager/cert-manager/compare/v1.11.4...v1.12.0) cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters. cert-manager v1.12 brings support for JSON logging, a lower memory footprint, support for ephemeral service account tokens with Vault, improved dependency management and support for the ingressClassName field. The full release notes are available at https://cert-manager.io/docs/release-notes/release-notes-1.12. #### Known issues - [`cmctl` API check](https://cert-manager.io/docs/installation/verify/) is broken in v1.12.1. We suggest that you do not upgrade `cmctl` to this version. The fix will be released in v1.12.2. See [#6116](https://github.com/cert-manager/cert-manager/issues/6116) for context. - cainjector contains a memory leak due to re-assignment of a log variable (see https://github.com/cert-manager/cert-manager/issues/6217). The fix will be released in v1.12.3. See https://github.com/cert-manager/cert-manager/pull/6232 for context. ### Community Thanks again to all open-source contributors with commits in this release, including: - [@malovme](https://github.com/malovme) - [@e96wic](https://github.com/e96wic) - [@ExNG](https://github.com/ExNG) - [@waterfoul](https://github.com/waterfoul) - [@jkroepke](https://github.com/jkroepke) - [@andrewsomething](https://github.com/andrewsomething) - [@yulng](https://github.com/yulng) - [@tobotg](https://github.com/tobotg) - [@maumontesilva](https://github.com/maumontesilva) - [@avi-08](https://github.com/avi-08) - [@vinzent](https://github.com/vinzent) - [@TrilokGeer](https://github.com/TrilokGeer) - [@g-gaston](https://github.com/g-gaston) - [@james-callahan](https://github.com/james-callahan) - [@lucacome](https://github.com/lucacome) - [@yanggangtony](https://github.com/yanggangtony) - [@vidarno](https://github.com/vidarno) - [@ctrought](https://github.com/ctrought) - [@Robfz](https://github.com/Robfz) - [@dsonck92](https://github.com/dsonck92) - [@rayandas](https://github.com/rayandas) - [@olekfur](https://github.com/olekfur) - [@ptrc-n](https://github.com/ptrc-n) - [@bradjones1](https://github.com/bradjones1) - [@gdvalle](https://github.com/gdvalle) Thanks also to the following cert-manager maintainers for their contributions during this release: - [@inteon](https://github.com/inteon) - [@wallrj](https://github.com/wallrj) - [@maelvls](https://github.com/maelvls) - [@SgtCoDFish](https://github.com/SgtCoDFish) - [@irbekrm](https://github.com/irbekrm) - [@jakexks](https://github.com/jakexks) - [@JoshVanL](https://github.com/JoshVanL) - [@munnerz](https://github.com/munnerz) Equally thanks to everyone who provided feedback, helped users and raised issues on Github and Slack, joined our meetings and talked to us at Kubecon! Special thanks to [@erikgb](https://github.com/erikgb) for continuously great input and feedback and to [@lucacome](https://github.com/lucacome) for always ensuring that our kube deps are up to date! Thanks also to the [CNCF](https://www.cncf.io/), which provides resources and support, and to the AWS open source team for being good community members and for their maintenance of the [PrivateCA Issuer](https://github.com/cert-manager/aws-privateca-issuer). In addition, massive thanks to [Jetstack](https://www.jetstack.io/) (by [Venafi](https://www.venafi.com/)) for contributing developer time and resources towards the continued maintenance of cert-manager projects. #### Changes by Kind ##### Feature - **POTENTIALLY BREAKING**: the cert-manager binaries and some tests have been split into separate Go modules, allowing them to be easily patched independently. This should have no impact if you simply run cert-manager in your cluster. If you import cert-manager binaries, integration tests or end-to-end tests in Go, you may need to make code changes in response to this. See https://cert-manager.io/docs/contributing/importing/ for more details. ([#5880](https://github.com/cert-manager/cert-manager/pull/5880), [@SgtCoDFish](https://github.com/SgtCoDFish)) - Added support for JSON logging (using --logging-format=json) ([#5828](https://github.com/cert-manager/cert-manager/pull/5828), [@malovme](https://github.com/malovme)) - Added the `--concurrent-workers` flag that lets you control the number of concurrent workers for each of our controllers. ([#5936](https://github.com/cert-manager/cert-manager/pull/5936), [@inteon](https://github.com/inteon)) - Adds `acme.solvers.http01.ingress.podTemplate.spec.imagePullSecrets` field to issuer spec to allow to specify image pull secrets for the ACME HTTP01 solver pod. ([#5801](https://github.com/cert-manager/cert-manager/pull/5801), [@malovme](https://github.com/malovme)) - Cainjector: - New flags were added to the cainjector binary. They can be used to modify what injectable kinds are enabled. If cainjector is only used as a cert-manager's internal component it is sufficient to only enable validatingwebhookconfigurations and mutatingwebhookconfigurations injectable resources; disabling the rest can improve memory consumption. By default all are enabled. - The `--watch-certs` flag was renamed to `--enable-certificates-data-source`. ([#5766](https://github.com/cert-manager/cert-manager/pull/5766), [@irbekrm](https://github.com/irbekrm)) - Helm: Added PodDisruptionBudgets for cert-manager components to the Helm chart (disabled by default). ([#3931](https://github.com/cert-manager/cert-manager/pull/3931), [@e96wic](https://github.com/e96wic)) - Helm: Egress 6443/TCP is now allowed in the webhook. This is required for OpenShift and OKD clusters for which the Kubernetes API server listens on port 6443 instead of 443. ([#5788](https://github.com/cert-manager/cert-manager/pull/5788), [@ExNG](https://github.com/ExNG)) - Helm: you can now add volumes and volume mounts via Helm variables for the cainjector, webhook, and startupapicheck. ([#5668](https://github.com/cert-manager/cert-manager/pull/5668), [@waterfoul](https://github.com/waterfoul)) - Helm: you can now enable the flags `--dns01-recursive-nameservers`, `--enable-certificate-owner-ref`, and `--dns01-recursive-nameservers-only` through Helm values. ([#5614](https://github.com/cert-manager/cert-manager/pull/5614), [@jkroepke](https://github.com/jkroepke)) - The DigitalOcean issuer now sets a cert-manager user agent string. ([#5869](https://github.com/cert-manager/cert-manager/pull/5869), [@andrewsomething](https://github.com/andrewsomething)) - The HTTP-01 solver can now be configured to create Ingresses with an `ingressClassName`. The credit goes to [@dsonck92](https://github.com/dsonck92) for implementing the initial PR. ([#5849](https://github.com/cert-manager/cert-manager/pull/5849), [@maelvls](https://github.com/maelvls)) - The Vault issuer can now be used with ephemeral Kubernetes tokens. With the new `serviceAccountRef` field, cert-manager generates a short-lived token associated to the service account to authenticate to Vault. Along with this new feature, we have added validation logic in the webhook in order to check the `vault.auth` field when creating an Issuer or ClusterIssuer. Previously, it was possible to create an Issuer or ClusterIssuer with an invalid value for `vault.auth`. ([#5502](https://github.com/cert-manager/cert-manager/pull/5502), [@maelvls](https://github.com/maelvls)) - The cert-manager controller container of the controller Pod now has a `/livez` endpoint and a default liveness probe, which fails if leader election has been lost and for some reason the process has not exited. The liveness probe is disabled by default. ([#5962](https://github.com/cert-manager/cert-manager/pull/5962), [@wallrj](https://github.com/wallrj)) - Upgraded Gateway API to v0.6.0. ([#5768](https://github.com/cert-manager/cert-manager/pull/5768), [@yulng](https://github.com/yulng)) - Webhook now logs requests to mutating/validating webhook (with `--v=5` flag) ([#5975](https://github.com/cert-manager/cert-manager/pull/5975), [@tobotg](https://github.com/tobotg)) ##### Design - Certificate issuances are always failed (and retried with a backoff) for denied or invalid CertificateRequests. This is not necessarily a breaking change as due to a race condition this may already have been the case. ([#5887](https://github.com/cert-manager/cert-manager/pull/5887), [@irbekrm](https://github.com/irbekrm)) - The cainjector controller can now use server-side apply to patch mutatingwebhookconfigurations, validatingwebhookconfigurations, apiservices, and customresourcedefinitions. This feature is currently in alpha and is not enabled by default. To enable server-side apply for the cainjector, add the flag --feature-gates=ServerSideApply=true to the deployment. ([#5991](https://github.com/cert-manager/cert-manager/pull/5991), [@inteon](https://github.com/inteon)) ##### Documentation - Helm: the dead links in `values.yaml` are now working ([#5999](https://github.com/cert-manager/cert-manager/pull/5999), [@SgtCoDFish](https://github.com/SgtCoDFish)) ##### Bug or Regression - Cmctl renew now prints an error message unless Certificate name(s) or --all are supplied ([#5896](https://github.com/cert-manager/cert-manager/pull/5896), [@maumontesilva](https://github.com/maumontesilva)) - Cmctl: In order work around a hardcoded Kubernetes version in Helm, we now use a fake kube-apiserver version when generating the helm template when running `cmctl x install`. ([#5720](https://github.com/cert-manager/cert-manager/pull/5720), [@irbekrm](https://github.com/irbekrm)) - Fix development environment and go vendoring on Linux arm64. ([#5810](https://github.com/cert-manager/cert-manager/pull/5810), [@SgtCoDFish](https://github.com/SgtCoDFish)) - Fix ordering of remote git tags when preparing integration tests ([#5910](https://github.com/cert-manager/cert-manager/pull/5910), [@SgtCoDFish](https://github.com/SgtCoDFish)) - Helm: the flag `--acme-http01-solver-image` given to the variable `acmesolver.extraArgs` now has precedence over the variable `acmesolver.image`. ([#5693](https://github.com/cert-manager/cert-manager/pull/5693), [@SgtCoDFish](https://github.com/SgtCoDFish)) - Ingress and Gateway resources will not be synced if deleted via [foreground cascading](https://kubernetes.io/docs/concepts/architecture/garbage-collection/#foreground-deletion). ([#5878](https://github.com/cert-manager/cert-manager/pull/5878), [@avi-08](https://github.com/avi-08)) - The auto-retry mechanism added in VCert 4.23.0 and part of cert-manager 1.11.0 ([#5674](https://github.com/cert-manager/cert-manager/issues/5674)) has been found to be faulty. Until this issue is fixed upstream, we now use a patched version of VCert. This patch will slowdown the issuance of certificates by 9% in case of heavy load on TPP. We aim to release at an ulterior date a patch release of cert-manager to fix this slowdown. ([#5805](https://github.com/cert-manager/cert-manager/pull/5805), [@inteon](https://github.com/inteon)) - Upgrade to go 1.19.6 along with newer helm and containerd versions and updated base images ([#5813](https://github.com/cert-manager/cert-manager/pull/5813), [@SgtCoDFish](https://github.com/SgtCoDFish)) - When using the `jks` and `pkcs12` fields on a Certificate resource with a CA issuer that doesn't set the `ca.crt` in the Secret resource, cert-manager no longer loop trying to copy `ca.crt` into `truststore.jks` or `truststore.p12`. ([#5972](https://github.com/cert-manager/cert-manager/pull/5972), [@vinzent](https://github.com/vinzent)) - When using the `literalSubject` field on a Certificate resource, the IPs, URIs, DNS names, and email addresses segments are now properly compared. ([#5747](https://github.com/cert-manager/cert-manager/pull/5747), [@inteon](https://github.com/inteon)) ##### Other (Cleanup or Flake) - ACME account registration is now re-verified if account key is manually changed. ([#5949](https://github.com/cert-manager/cert-manager/pull/5949), [@TrilokGeer](https://github.com/TrilokGeer)) - Add `make go-workspace` target for generating a go.work file for local development ([#5935](https://github.com/cert-manager/cert-manager/pull/5935), [@SgtCoDFish](https://github.com/SgtCoDFish)) - Added a Makefile target to build a standalone E2E test binary: make e2e-build ([#5804](https://github.com/cert-manager/cert-manager/pull/5804), [@wallrj](https://github.com/wallrj)) - Bump keystore-go to v4.4.1 to work around an upstream rewrite of history ([#5724](https://github.com/cert-manager/cert-manager/pull/5724), [@g-gaston](https://github.com/g-gaston)) - Bump the distroless base images ([#5929](https://github.com/cert-manager/cert-manager/pull/5929), [@maelvls](https://github.com/maelvls)) - Bumps base images ([#5793](https://github.com/cert-manager/cert-manager/pull/5793), [@irbekrm](https://github.com/irbekrm)) - Cainjector memory improvements: removes second cache of secrets, CRDs, validating/mutatingwebhookconfigurations and APIServices that should reduce memory consumption by about half. \*\*BREAKING:\*- users who are relying on cainjector to work when `certificates.cert-manager.io` CRD is not installed in the cluster, now need to pass `--watch-certificates=false` flag to cainjector else it will not start. Users who only use cainjector as cert-manager's internal component and have a large number of `Certificate` resources in cluster can pass `--watch-certificates=false` to avoid cainjector from caching `Certificate` resources and save some memory. ([#5746](https://github.com/cert-manager/cert-manager/pull/5746), [@irbekrm](https://github.com/irbekrm)) - Cainjector now only reconciles annotated objects of injectable kind. ([#5764](https://github.com/cert-manager/cert-manager/pull/5764), [@irbekrm](https://github.com/irbekrm)) - Container images are have an OCI source label ([#5722](https://github.com/cert-manager/cert-manager/pull/5722), [@james-callahan](https://github.com/james-callahan)) - Enable cmctl to be imported by third parties ([#6050](https://github.com/cert-manager/cert-manager/pull/6050), [@jetstack-bot](https://github.com/jetstack-bot)) - The acmesolver pods created by cert-manager now have `automountServiceAccountToken` turned off. ([#5754](https://github.com/cert-manager/cert-manager/pull/5754), [@wallrj](https://github.com/wallrj)) - The controller binary now uses much less memory on Kubernetes clusters with large or numerous Secret resources. The controller now ignores the contents of Secrets that aren't relevant to cert-manager. This functionality is currently placed behind `SecretsFilteredCaching` feature flag. The filtering mechanism might, in some cases, slightly slow down issuance or cause additional requests to kube-apiserver because unlabelled Secret resources that cert-manager controller needs will now be retrieved from kube-apiserver instead of being cached locally. To prevent this from happening, users can label all issuer Secret resources with the `controller.cert-manager.io/fao: true` label. ([#5824](https://github.com/cert-manager/cert-manager/pull/5824), [@irbekrm](https://github.com/irbekrm)) - The controller memory usage has been further decreased by ignoring annotations, labels and managed fields when caching Secret resources. ([#5966](https://github.com/cert-manager/cert-manager/pull/5966), [@irbekrm](https://github.com/irbekrm)) - The controller now makes fewer calls to the ACME server. **POTENTIALLY BREAKING**: this PR slightly changes how the name of the Challenge resources are calculated. To avoid duplicate issuances due to the Challenge resource being recreated, ensure that there is no in-progress ACME certificate issuance when you upgrade to this version of cert-manager. ([#5901](https://github.com/cert-manager/cert-manager/pull/5901), [@irbekrm](https://github.com/irbekrm)) - The memory usage of the controller has been reduced by only caching the metadata of Pods and Services. ([#5976](https://github.com/cert-manager/cert-manager/pull/5976), [@irbekrm](https://github.com/irbekrm)) - The number of calls made to the ACME server during the controller startup has been reduced by storing the private key hash in the Issuer's status. ([#6006](https://github.com/cert-manager/cert-manager/pull/6006), [@vidarno](https://github.com/vidarno)) - Updates Kubernetes libraries to `v0.26.2`. ([#5820](https://github.com/cert-manager/cert-manager/pull/5820), [@lucacome](https://github.com/lucacome)) - Updates Kubernetes libraries to `v0.26.3`. ([#5907](https://github.com/cert-manager/cert-manager/pull/5907), [@lucacome](https://github.com/lucacome)) - Updates Kubernetes libraries to `v0.27.1`. ([#5961](https://github.com/cert-manager/cert-manager/pull/5961), [@lucacome](https://github.com/lucacome)) - Updates base images ([#5832](https://github.com/cert-manager/cert-manager/pull/5832), [@irbekrm](https://github.com/irbekrm)) - Upgrade to Go 1.20 ([#5969](https://github.com/cert-manager/cert-manager/pull/5969), [@wallrj](https://github.com/wallrj)) - Upgrade to go 1.19.5 ([#5712](https://github.com/cert-manager/cert-manager/pull/5712), [@yanggangtony](https://github.com/yanggangtony)) - Validates that `certificate.spec.secretName` is a valid `Secret` name ([#5967](https://github.com/cert-manager/cert-manager/pull/5967), [@avi-08](https://github.com/avi-08)) - We are now testing with Kubernetes v1.27.1 by default. ([#5979](https://github.com/cert-manager/cert-manager/pull/5979), [@irbekrm](https://github.com/irbekrm)) - `certificate.spec.secretName` Secrets will now be labelled with `controller.cert-manager.io/fao` label ([#5660](https://github.com/cert-manager/cert-manager/pull/5660), [@irbekrm](https://github.com/irbekrm)) ##### Uncategorized - We have replaced our python boilerplate checker with an installed Go version, removing the need to have Python installed when developing or building cert-manager. ([#6000](https://github.com/cert-manager/cert-manager/pull/6000), [@SgtCoDFish](https://github.com/SgtCoDFish)) ### [`v1.11.4`](https://github.com/cert-manager/cert-manager/releases/tag/v1.11.4) [Compare Source](https://github.com/cert-manager/cert-manager/compare/v1.11.3...v1.11.4) #### Changes by Kind ##### Other (Cleanup or Flake) - Resolved docker/docker trivy CVE alert ([#6164](https://github.com/cert-manager/cert-manager/issues/6164), [@inteon](https://github.com/inteon)) - Upgraded base images ([#6128](https://github.com/cert-manager/cert-manager/issues/6128), [@SgtCoDFish](https://github.com/SgtCoDFish)) #### Dependencies ##### Changed - github.com/docker/distribution: [v2.8.1+incompatible → v2.8.2+incompatible](https://github.com/docker/distribution/compare/v2.8.1...v2.8.2) ### [`v1.11.3`](https://github.com/cert-manager/cert-manager/releases/tag/v1.11.3) [Compare Source](https://github.com/cert-manager/cert-manager/compare/v1.11.2...v1.11.3) v1.11.3 mostly contains ACME library changes. API Priority and Fairness feature is now disabled in the external webhook's extension apiserver. #### Changes by Kind ##### Other (Cleanup or Flake) - API Priority and Fairness controller is now disabled in extension apiserver for DNS webhook implementation. ([#6092](https://github.com/cert-manager/cert-manager/pull/6092), [@irbekrm](https://github.com/irbekrm)) - Adds a warning for folks to not use controller feature gates helm value to configure webhook feature gates ([#6101](https://github.com/cert-manager/cert-manager/pull/6101), [@irbekrm](https://github.com/irbekrm)) ### [`v1.11.2`](https://github.com/cert-manager/cert-manager/releases/tag/v1.11.2) [Compare Source](https://github.com/cert-manager/cert-manager/compare/v1.11.1...v1.11.2) ### Changelog since v1.11.1 #### Changes by Kind ##### Bug or Regression - Build with go 1.19.9 ([#6014](https://github.com/cert-manager/cert-manager/pull/6014), [@SgtCoDFish](https://github.com/SgtCoDFish)) ##### Other (Cleanup or Flake) - Bump the distroless base images ([#5930](https://github.com/cert-manager/cert-manager/pull/5930), [@maelvls](https://github.com/maelvls)) - Bumps Docker libraries to fix vulnerability scan alert for CVE-2023-28840, CVE-2023-28841, CVE-2023-28842 ([#6037](https://github.com/cert-manager/cert-manager/pull/6037), [@irbekrm](https://github.com/irbekrm)) Cert-manager was not actually affected by these CVEs which are all to do with Docker daemon's overlay network. - Bumps Kube libraries v0.26.0 -> v0.26.4 ([#6038](https://github.com/cert-manager/cert-manager/pull/6038), [@irbekrm](https://github.com/irbekrm)) This might help with running cert-manager v1.11 on Kubernetes v1.27, see [#6038](https://github.com/cert-manager/cert-manager/pull/6038) ### [`v1.11.1`](https://github.com/cert-manager/cert-manager/releases/tag/v1.11.1) [Compare Source](https://github.com/cert-manager/cert-manager/compare/v1.11.0...v1.11.1) cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters. In v1.11.1, we updated the base images used for cert-manager containers. In addition, the users of the Venafi issuer will see less certificates repeatedly failing. If you are a user of Venafi TPP and have been having issues with the error message `This certificate cannot be processed while it is in an error state. Fix any errors, and then click Retry`, please use this version. #### Changes since v1.11.0 ##### Bug or Regression - Bump helm and other dependencies to fix CVEs, along with upgrading go and base images ([#5815](https://github.com/cert-manager/cert-manager/issues/5815), [@SgtCoDFish](https://github.com/SgtCoDFish)) - Bump the distroless base images ([#5930](https://github.com/cert-manager/cert-manager/issues/5930), [@maelvls](https://github.com/maelvls)) - The auto-retry mechanism added in VCert 4.23.0 and part of cert-manager 1.11.0 ([#5674](https://github.com/cert-manager/cert-manager/issues/5674)) has been found to be faulty. Until this issue is fixed upstream, we now use a patched version of VCert. This patch will slowdown the issuance of certificates by 9% in case of heavy load on TPP. We aim to release at an ulterior date a patch release of cert-manager to fix this slowdown. ([#5819](https://github.com/cert-manager/cert-manager/issues/5819), [@maelvls](https://github.com/maelvls)) - Use a fake-kube apiserver version when generating helm template in `cmctl x install`, to work around a hardcoded Kubernetes version in Helm. ([#5726](https://github.com/cert-manager/cert-manager/issues/5726), [@SgtCoDFish](https://github.com/SgtCoDFish)) ##### Other (Cleanup or Flake) - Bump keystore-go to v4.4.1 to work around an upstream rewrite of history ([#5730](https://github.com/cert-manager/cert-manager/issues/5730), [@SgtCoDFish](https://github.com/SgtCoDFish)) ### [`v1.11.0`](https://github.com/cert-manager/cert-manager/releases/tag/v1.11.0) [Compare Source](https://github.com/cert-manager/cert-manager/compare/v1.10.2...v1.11.0) cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters. `v1.11.0` includes a drastic reduction in cert-manager's runtime memory usage, a slew of improvements to AKS integrations and various other tweaks, fixes and improvements, all towards cert-manager's goal of being the best way to handle certificates in modern Cloud Native applications. #### Community Thanks again to all open-source contributors with commits in this release, including: - [@cmcga1125](https://github.com/cmcga1125) - [@karlschriek](https://github.com/karlschriek) - [@lvyanru8200](https://github.com/lvyanru8200) - [@mmontes11](https://github.com/mmontes11) - [@pinkfloydx33](https://github.com/pinkfloydx33) - [@sathyanarays](https://github.com/sathyanarays) - [@weisdd](https://github.com/weisdd) - [@yann-soubeyrand](https://github.com/yann-soubeyrand) - [@joycebrum](https://github.com/joycebrum) - [@Git-Jiro](https://github.com/Git-Jiro) - [@thib-mary](https://github.com/thib-mary) - [@yk](https://github.com/yk) - [@RomanenkoDenys](https://github.com/RomanenkoDenys) - [@lucacome](https://github.com/lucacome) - [@yanggangtony](https://github.com/yanggangtony) Thanks also to the following cert-manager maintainers for their contributions during this release: - [@wallrj](https://github.com/wallrj) - [@irbekrm](https://github.com/irbekrm) - [@maelvls](https://github.com/maelvls) - [@SgtCoDFish](https://github.com/SgtCoDFish) - [@inteon](https://github.com/inteon) - [@jakexks](https://github.com/jakexks) - [@JoshVanL](https://github.com/JoshVanL) Thanks also to the [CNCF](https://www.cncf.io/), which provides resources and support, and to the AWS open source team for being good community members and for their maintenance of the [PrivateCA Issuer](https://github.com/cert-manager/aws-privateca-issuer). In addition, massive thanks to [Jetstack](https://www.jetstack.io/) (by [Venafi](https://www.venafi.com/)) for contributing developer time and resources towards the continued maintenance of cert-manager projects. #### Changes since cert-manager `v1.10` For an overview of new features, see the [v1.11 release notes](https://cert-manager.io/docs/release-notes/release-notes-1.11/)! ##### Feature - Helm: allow configuring the image used by ACME HTTP-01 solver ([#5554](https://github.com/cert-manager/cert-manager/issues/5554), [@yann-soubeyrand](https://github.com/yann-soubeyrand)) - Add the `--max-concurrent-challenges` controller flag to the helm chart ([#5638](https://github.com/cert-manager/cert-manager/issues/5638), [@lvyanru8200](https://github.com/lvyanru8200)) - Adds the ability to specify a custom CA bundle in Issuers when connecting to an ACME server ([#5644](https://github.com/cert-manager/cert-manager/issues/5644), [@SgtCoDFish](https://github.com/SgtCoDFish)) - Enable testing against Kubernetes 1.26 and test with Kubernetes 1.26 by default ([#5646](https://github.com/cert-manager/cert-manager/issues/5646), [@SgtCoDFish](https://github.com/SgtCoDFish)) - Experimental make targets for pushing images to an OCI registry using `ko` and redeploying cert-manager to the cluster referenced by your current KUBECONFIG context. ([#5655](https://github.com/cert-manager/cert-manager/issues/5655), [@wallrj](https://github.com/wallrj)) - Add ability to run acmesolver pods as root if desired. The default is still to run as non-root. ([#5546](https://github.com/cert-manager/cert-manager/issues/5546), [@cmcga1125](https://github.com/cmcga1125)) - Add support for DC and UID in `LiteralSubject` field, all mandatory OIDs are now supported for LDAP certificates (rfc4514). ([#5587](https://github.com/cert-manager/cert-manager/issues/5587), [@SpectralHiss](https://github.com/SpectralHiss)) - Add support for Workload Identity to AzureDNS resolver ([#5570](https://github.com/cert-manager/cert-manager/issues/5570), [@weisdd](https://github.com/weisdd)) - Breaking: updates the gateway API integration to use the more stable v1beta1 API version. Any users of the cert-manager `ExperimentalGatewayAPISupport` alpha feature must ensure that `v1beta` of Gateway API is installed in cluster. ([#5583](https://github.com/cert-manager/cert-manager/issues/5583), [@lvyanru8200](https://github.com/lvyanru8200)) - Certificate secrets get refreshed if the keystore format change ([#5597](https://github.com/cert-manager/cert-manager/issues/5597), [@sathyanarays](https://github.com/sathyanarays)) - Introducing UseCertificateRequestBasicConstraints feature flag to enable Basic Constraints in the Certificate Signing Request ([#5552](https://github.com/cert-manager/cert-manager/issues/5552), [@sathyanarays](https://github.com/sathyanarays)) - Return error when Gateway has a cross-namespace secret ref ([#5613](https://github.com/cert-manager/cert-manager/issues/5613), [@mmontes11](https://github.com/mmontes11)) - Signers fire an event on CertificateRequests which have not been approved yet. Used for informational purposes so users understand why a request is not progressing. ([#5535](https://github.com/cert-manager/cert-manager/issues/5535), [@JoshVanL](https://github.com/JoshVanL)) ##### Bug or Regression - Don't log errors relating to self-signed issuer checks for external issuers ([#5681](https://github.com/cert-manager/cert-manager/issues/5681), [@SgtCoDFish](https://github.com/SgtCoDFish)) - Fixed a bug in AzureDNS resolver that led to early reconciliations in misconfigured Workload Identity-enabled setups (when Federated Identity Credential is not linked with a controller's k8s service account) ([#5663](https://github.com/cert-manager/cert-manager/issues/5663), [@weisdd](https://github.com/weisdd)) - Use manually specified temporary directory template when verifying CRDs ([#5680](https://github.com/cert-manager/cert-manager/issues/5680), [@SgtCoDFish](https://github.com/SgtCoDFish)) - `vcert` was upgraded to `v4.23.0`, fixing two bugs in cert-manager. The first bug was preventing the Venafi issuer from renewing certificates when using TPP has been fixed. You should no longer see your certificates getting stuck with `WebSDK CertRequest Module Requested Certificate` or `This certificate cannot be processed while it is in an error state. Fix any errors, and then click Retry.`. The second bug that was fixed prevented the use of `algorithm: Ed25519` in Certificate resources with VaaS. ([#5674](https://github.com/cert-manager/cert-manager/issues/5674), [@maelvls](https://github.com/maelvls)) - Upgrade `golang/x/net` to fix CVE-2022-41717 ([#5632](https://github.com/cert-manager/cert-manager/issues/5632), [@SgtCoDFish](https://github.com/SgtCoDFish)) - Bug fix: When using feature gates with the helm chart, enable feature gate flags on webhook as well as controller ([#5584](https://github.com/cert-manager/cert-manager/issues/5584), [@lvyanru8200](https://github.com/lvyanru8200)) - Fix `golang.org/x/text` vulnerability ([#5562](https://github.com/cert-manager/cert-manager/issues/5562), [@SgtCoDFish](https://github.com/SgtCoDFish)) - Fixes a bug that caused the Vault issuer to omit the Vault namespace in requests to the Vault API. ([#5591](https://github.com/cert-manager/cert-manager/issues/5591), [@wallrj](https://github.com/wallrj)) - The Venafi Issuer now supports TLS 1.2 renegotiation, so that it can connect to TPP servers where the vedauth API endpoints are configured to *accept* client certificates. (Note: This does not mean that the Venafi Issuer supports client certificate authentication). ([#5568](https://github.com/cert-manager/cert-manager/issues/5568), [@wallrj](https://github.com/wallrj)) - Upgrade to go 1.19.4 to fix CVE-2022-41717 ([#5619](https://github.com/cert-manager/cert-manager/issues/5619), [@SgtCoDFish](https://github.com/SgtCoDFish)) - Upgrade to latest go minor release ([#5559](https://github.com/cert-manager/cert-manager/issues/5559), [@SgtCoDFish](https://github.com/SgtCoDFish)) - Ensure `extraArgs` in Helm takes precedence over the new acmesolver image options ([#5702](https://github.com/cert-manager/cert-manager/issues/5702), [@SgtCoDFish](https://github.com/SgtCoDFish)) - Fix cainjector's --namespace flag. Users who want to prevent cainjector from reading all Secrets and Certificates in all namespaces (i.e to prevent excessive memory consumption) can now scope it to a single namespace using the --namespace flag. A cainjector that is only used as part of cert-manager installation only needs access to the cert-manager installation namespace. ([#5694](https://github.com/cert-manager/cert-manager/issues/5694), [@irbekrm](https://github.com/irbekrm)) - Fixes a bug where cert-manager controller was caching all Secrets twice ([#5691](https://github.com/cert-manager/cert-manager/issues/5691), [@irbekrm](https://github.com/irbekrm)) ##### Other - `certificate.spec.secretName` Secrets will now be labelled with the `controller.cert-manager.io/fao` label ([#5703](https://github.com/cert-manager/cert-manager/issues/5703), [@irbekrm](https://github.com/irbekrm)) - Upgrade to go 1.19.5 ([#5714](https://github.com/cert-manager/cert-manager/issues/5714), [@yanggangtony](https://github.com/yanggangtony)) ##### Known issues - There is a bug in conformance tests for external DNS webhook implementations that was introduced in this release, see https://github.com/cert-manager/cert-manager/issues/5725 If you are importing cert-manager as a library to run conformance tests against your DNS webhook solver implementation, please make sure that you import a version with a fix, see https://github.com/cert-manager/cert-manager/issues/5725#issuecomment-1397245757 ### [`v1.10.2`](https://github.com/cert-manager/cert-manager/releases/tag/v1.10.2) [Compare Source](https://github.com/cert-manager/cert-manager/compare/v1.10.1...v1.10.2) cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters. v1.10.2 is primarily a performance enhancement release which might reduce memory consumption by up to 50% in some cases thanks to some brilliant work by [@irbekrm](https://github.com/irbekrm)! :tada: It also patches several vulnerabilities reported by scanners and updates the base images used for cert-manager containers. In addition, it removes a potentially confusing log line which had been introduced in v1.10.0 which implied that an error had occurred when using external issuers even though there'd been no error. #### Changes since `v1.10.1` ##### Feature - Enable support for Kubernetes 1.26 in tests ([#5647](https://github.com/cert-manager/cert-manager/issues/5647), [@SgtCoDFish](https://github.com/SgtCoDFish)) ##### Bug or Regression - Fixes a bug where the cert-manager controller was caching all Secrets twice ([#5704](https://github.com/cert-manager/cert-manager/issues/5704), [@irbekrm](https://github.com/irbekrm)) - Bump helm version to fix CVE-2022-23525 ([#5676](https://github.com/cert-manager/cert-manager/issues/5676), [@SgtCoDFish](https://github.com/SgtCoDFish)) - Don't log errors relating to selfsigned issuer checks for external issuers ([#5687](https://github.com/cert-manager/cert-manager/issues/5687), [@SgtCoDFish](https://github.com/SgtCoDFish)) - Fix `golang.org/x/text` vulnerability ([#5592](https://github.com/cert-manager/cert-manager/issues/5592), [@SgtCoDfish](https://github.com/SgtCoDfish)) - Upgrade golang/x/net to fix CVE-2022-41717 ([#5635](https://github.com/cert-manager/cert-manager/issues/5635), [@SgtCoDFish](https://github.com/SgtCoDFish)) - Upgrade to go 1.19.4 to fix CVE-2022-41717 ([#5620](https://github.com/cert-manager/cert-manager/issues/5620), [@SgtCoDfish](https://github.com/SgtCoDfish)) - Use manually specified tmpdir template when verifying CRDs ([#5682](https://github.com/cert-manager/cert-manager/issues/5682), [@SgtCoDFish](https://github.com/SgtCoDFish)) ##### Other (Cleanup or Flake) - Bump distroless base images to latest versions ([#5677](https://github.com/cert-manager/cert-manager/issues/5677), [@SgtCoDFish](https://github.com/SgtCoDFish)) ### [`v1.10.1`](https://github.com/cert-manager/cert-manager/releases/tag/v1.10.1) [Compare Source](https://github.com/cert-manager/cert-manager/compare/v1.10.0...v1.10.1) cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters. cert-manager v1.10.1 is a bug fix release which fixes a problem which prevented the Venafi Issuer from connecting to TPP servers where the vedauth API endpoints were configured to accept client certificates. It is also compiled with a newer version of Go 1.19 (v1.19.3) which fixes some vulnerabilities in the Go standard library. #### Changes since `v1.10.0` ##### Bug or Regression - The Venafi Issuer now supports TLS 1.2 renegotiation, so that it can connect to TPP servers where the `vedauth` API endpoints are configured to *accept* client certificates. (Note: This does not mean that the Venafi Issuer supports client certificate authentication). ([#5576](https://github.com/cert-manager/cert-manager/pull/5371), [@wallrj](https://github.com/wallrj)) - Upgrade to latest go patch release ([#5560](https://github.com/cert-manager/cert-manager/pull/5560), [@SgtCoDFish](https://github.com/SgtCoDFish) ) ### [`v1.10.0`](https://github.com/cert-manager/cert-manager/releases/tag/v1.10.0) [Compare Source](https://github.com/cert-manager/cert-manager/compare/v1.9.2...v1.10.0) cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters. Version 1.10 adds a variety of quality-of-life fixes and features including improvements to the test suite. #### Changes since v1.9.1 ##### Breaking Changes (You MUST read this before you upgrade!) ##### Container Name Changes This change is only relevant if you install cert-manager using Helm or the static manifest files. `v1.10.0` [changes the names](https://github.com/cert-manager/cert-manager/pull/5410) of containers in pods created by cert-manager. The names are changed to better reflect what they do; for example, the container in the controller pod had its name changed from `cert-manager` to `cert-manager-controller`, and the webhook pod had its container name changed from `cert-manager` to `cert-manager-webhook`. This change could cause a break if you: 1. Use Helm or the static manifests, and 2. Have scripts, tools or tasks which rely on the names of the cert-manager containers being static If both of these are true, you may need to update your automation before you upgrade. ##### On OpenShift the cert-manager Pods may fail until you modify Security Context Constraints In cert-manager 1.10 the [secure computing (seccomp) profile](https://kubernetes.io/docs/tutorials/security/seccomp/) for all the Pods is set to RuntimeDefault. (See [#5259](https://github.com/cert-manager/cert-manager/issues/5259).) The securityContext fields of the Pod are set as follows: ```yaml ... ### ref: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ securityContext: seccompProfile: type: RuntimeDefault ... ``` On some versions and configurations of OpenShift this can cause the Pod to be rejected by the [Security Context Constraints admission webhook](https://docs.openshift.com/container-platform/4.10/authentication/managing-security-context-constraints.html#admission_configuring-internal-oauth). Read [full release notes](https://cert-manager.io/docs/release-notes/release-notes-1.10#on-openshift-the-cert-manager-pods-may-fail-until-you-modify-security-context-constraints) to learn if this might affect you and how to fix it. ##### Feature - Add `issuer_name`, `issuer_kind` and `issuer_group` labels to `certificate_expiration_timestamp_seconds`, `certmanager_certificate_renewal_timestamp_seconds` and `certmanager_certificate_ready_status` metrics ([#5461](https://github.com/cert-manager/cert-manager/issues/5461), [@dkulchinsky](https://github.com/dkulchinsky)) - Add make targets for running scans with trivy against locally built containers ([#5358](https://github.com/cert-manager/cert-manager/issues/5358), [@SgtCoDFish](https://github.com/SgtCoDFish)) - CertificateRequests: requests that use the SelfSigned Issuer will be re-reconciled when the target private key Secret has been informed `cert-manager.io/private-key-secret-name`. This resolves an issue whereby a request would never be signed when the target Secret was not created or was misconfigured before the request. ([#5336](https://github.com/cert-manager/cert-manager/issues/5336), [@JoshVanL](https://github.com/JoshVanL)) - CertificateSigningRequests: requests that use the SelfSigned Issuer will be re-reconciled when the target private key Secret has been informed `experimental.cert-manager.io/private-key-secret-name`. This resolves an issue whereby a request would never be signed when the target Secret was not created or was misconfigured before the request. CertificateSigningRequets will also now no-longer be marked as failed when the target private key Secret is malformed- now only firing an event. When the Secret data is resolved, the request will attempt issuance. ([#5379](https://github.com/cert-manager/cert-manager/issues/5379), [@JoshVanL](https://github.com/JoshVanL)) - Upgraded Gateway API to v0.5.0 ([#5376](https://github.com/cert-manager/cert-manager/issues/5376), [@inteon](https://github.com/inteon)) - Add caBundleSecretRef to the Vault Issuer to allow referencing the Vault CA Bundle with a Secret. Cannot be used in conjunction with the in-line caBundle field. ([#5387](https://github.com/cert-manager/cert-manager/issues/5387), [@Tolsto](https://github.com/Tolsto)) - The feature to create certificate requests with the name being a function of certificate name and revision has been introduced under the feature flag "StableCertificateRequestName" and it is disabled by default. This helps to prevent the error "multiple CertificateRequests were found for the 'next' revision...". ([#5487](https://github.com/cert-manager/cert-manager/issues/5487), [@sathyanarays](https://github.com/sathyanarays)) - Helm: Added a new parameter `commonLabels` which gives you the capability to add the same label on all the resource deployed by the chart. ([#5208](https://github.com/cert-manager/cert-manager/issues/5208), [@thib-mary](https://github.com/thib-mary)) ##### Bug or Regression - CertificateSigningRequest: no longer mark a request as failed when using the SelfSigned issuer, and the Secret referenced in `experimental.cert-manager.io/private-key-secret-name` doesn't exist. ([#5323](https://github.com/cert-manager/cert-manager/issues/5323), [@JoshVanL](https://github.com/JoshVanL)) - DNS Route53: Remove incorrect validation which rejects solvers that don't define either a `accessKeyID` or `secretAccessKeyID`. ([#5339](https://github.com/cert-manager/cert-manager/issues/5339), [@JoshVanL](https://github.com/JoshVanL)) - Enhanced securityContext for PSS/restricted compliance. ([#5259](https://github.com/cert-manager/cert-manager/issues/5259), [@joebowbeer](https://github.com/joebowbeer)) **Breaking**: this might require changes for OpenShift deployments. Read [full release notes](https://cert-manager.io/docs/release-notes/release-notes-1.10#on-openshift-the-cert-manager-pods-may-fail-until-you-modify-security-context-constraints) to learn more. - Fix issue where CertificateRequests marked as InvalidRequest did not properly trigger issuance failure handling leading to 'stuck' requests ([#5366](https://github.com/cert-manager/cert-manager/issues/5366), [@munnerz](https://github.com/munnerz)) - `cmctl` and `kubectl cert-manager` now report their actual versions instead of "canary", fixing issue [#5020](https://github.com/cert-manager/cert-manager/issues/5020) ([#5022](https://github.com/cert-manager/cert-manager/issues/5022), [@maelvls](https://github.com/maelvls)) ##### Other - Avoid hard-coding release namespace in helm chart ([#5163](https://github.com/cert-manager/cert-manager/issues/5163), [@james-callahan](https://github.com/james-callahan)) - Bump cert-manager's version of Go to `1.19` ([#5466](https://github.com/cert-manager/cert-manager/issues/5466), [@lucacome](https://github.com/lucacome)) - Remove `.bazel` and `.bzl` files from cert-manager now that bazel has been fully replaced ([#5340](https://github.com/cert-manager/cert-manager/issues/5340), [@SgtCoDFish](https://github.com/SgtCoDFish)) - Updates Kubernetes libraries to `v0.25.2`. ([#5456](https://github.com/cert-manager/cert-manager/issues/5456), [@lucacome](https://github.com/lucacome)) - Add annotations for ServiceMonitor in helm chart ([#5401](https://github.com/cert-manager/cert-manager/issues/5401), [@sathieu](https://github.com/sathieu)) - Helm: Add NetworkPolicy support ([#5417](https://github.com/cert-manager/cert-manager/issues/5417), [@mjudeikis](https://github.com/mjudeikis)) - To help troubleshooting, make the container names unique. BREAKING: this change will break scripts/ CI that depend on `cert-manager` being the container name. ([#5410](https://github.com/cert-manager/cert-manager/issues/5410), [@rgl](https://github.com/rgl)) #### Thank You! Thank you to the following community members who had a merged PR for this version - your contributions are at the heart of everything we do! - [@joebowbeer](https://github.com/joebowbeer) - [@rgl](https://github.com/rgl) - [@lucacome](https://github.com/lucacome) - [@sathieu](https://github.com/sathieu) - [@mjudeikis](https://github.com/mjudeikis) - [@james-callahan](https://github.com/james-callahan) - [@dkulchinsky](https://github.com/dkulchinsky) - [@thib-mary](https://github.com/thib-mary) - [@Tolsto](https://github.com/Tolsto) - [@sathyanarays](https://github.com/sathyanarays) Thanks also to the following maintainers who worked on cert-manager 1.10: - [@irbekrm](https://github.com/irbekrm) - [@SgtCoDFish](https://github.com/SgtCoDFish) - [@jakexks](https://github.com/jakexks) - [@wallrj](https://github.com/wallrj) - [@maelvls](https://github.com/maelvls) - [@JoshVanL](https://github.com/JoshVanL) - [@jahrlin](https://github.com/jahrlin) - [@munnerz](https://github.com/munnerz) - [@inteon](https://github.com/inteon) ### [`v1.9.2`](https://github.com/cert-manager/cert-manager/releases/tag/v1.9.2) [Compare Source](https://github.com/cert-manager/cert-manager/compare/v1.9.1...v1.9.2) cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters. cert-manager `v1.9.2` is a bug fix release which fixes an issue where CertificateRequests marked as InvalidRequest did not properly trigger issuance failure handling leading to 'stuck' requests, and a problem which prevented the Venafi Issuer from connecting to TPP servers where the `vedauth` API endpoints were configured to *accept* client certificates. It is also compiled with a newer version of Go 1.18 (`v1.18.8`) which fixes some vulnerabilities in the Go standard library. #### Changes since `v1.9.1` ##### Bug or Regression - Fix issue where CertificateRequests marked as InvalidRequest did not properly trigger issuance failure handling leading to 'stuck' requests. ([#5371](https://github.com/cert-manager/cert-manager/pull/5371), [@munnerz](https://github.com/munnerz) ) - The Venafi Issuer now supports TLS 1.2 renegotiation, so that it can connect to TPP servers where the `vedauth` API endpoints are configured to *accept* client certificates. (Note: This does not mean that the Venafi Issuer supports client certificate authentication). ([#5577](https://github.com/cert-manager/cert-manager/pull/5577), [@wallrj](https://github.com/wallrj)) - Upgrade to latest go patch release. ([#5561](https://github.com/cert-manager/cert-manager/pull/5561), [@SgtCoDFish](https://github.com/SgtCoDFish)) ### [`v1.9.1`](https://github.com/cert-manager/cert-manager/releases/tag/v1.9.1) [Compare Source](https://github.com/cert-manager/cert-manager/compare/v1.9.0...v1.9.1) cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters. Version 1.9.1 is a bugfix release which removes an incorrect check in the Route53 DNS solver. This accidental change prevented the use of credentials derived from instance metadata or AWS pod metadata. Thanks to [@danquack](https://github.com/danquack) and [@ArchiFleKs](https://github.com/ArchiFleKs) for raising this issue, and [@danquack](https://github.com/danquack) and [@JoshVanL](https://github.com/JoshVanL) for fixing it! ### Changes since v1.9.0 #### Bug - DNS Route53: Remove incorrect validation which rejects solvers that don't define either a `accessKeyID` or `secretAccessKeyID`. ([#5341](https://github.com/cert-manager/cert-manager/pull/5341), [@JoshVanL](https://github.com/JoshVanL) [@danquack](https://github.com/danquack) ) ### [`v1.9.0`](https://github.com/cert-manager/cert-manager/releases/tag/v1.9.0) [Compare Source](https://github.com/cert-manager/cert-manager/compare/v1.8.2...v1.9.0) cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters. The new version adds alpha support for using cert-manager `Certificate`s in scenarios where the ordering of the Relative Distinguished Names (RDN) sequence that constitutes an X.509 certificate's subject needs to be preserved; improves the ability to configure the `Certificate` created via ingress-shim using annotations on the `Ingress` resource; introduces various changes/improvements in contributor flow; and finishes the new make-based contributor workflow. #### Major Themes ##### Literal Certificate Subjects cert-manager's `Certificate` allows users to configure the subject fields of the X.509 certificate via `spec.subject` and `spec.commonName` fields. The [X.509 spec](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.6) states that the subject is an (ordered) sequence of Relative Distinguished Names (RDN). cert-manager does not strictly abide by this spec when encoding the subject fields from the `Certificate` spec. For example, the order of the RDN sequence may not be preserved. This is because cert-manager uses Go's libraries for X.509 certificates, and the Go libraries don't preserve ordering. For the vast majority of users this does not matter, but there are specific cases that require defining the exact ordered RDN sequence. For example, if the certificate is used for LDAP authentication and the RDN sequence represents a [location in LDAP directory tree](https://ldapwiki.com/wiki/Directory%20Information%20Tree). See [`cert-manager#3203`](https://github.com/cert-manager/cert-manager/issues/3203). For these use cases, a new alpha `LiteralSubject` field has been added to the `Certificate` spec where users can pass a literal RDN sequence: ```yaml apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: test spec: secretName: test literalSubject: "C=US,O=myOrg,CN=someName" ``` To use this field, the alpha feature gate `LiteralCertificateSubject` needs to be enabled on both the cert-manager controller and webhook. Bear in mind that `spec.literalSubject` is mutually exclusive with `spec.commonName` and `spec.subject`. This feature is aimed at the specific scenario where an exact RDN sequence needs to be defined. We do not intend to deprecate the existing `spec.subject` and `spec.commonName` fields and we recommend that folks keep using those fields in all other cases; they're simpler, have better validation and are more obvious to read and change. ##### ingress-shim `Certificate` Configuration cert-manager 1.9 adds the ability to configure an ingress-shim `Certificate`'s `spec.revisionHistoryLimit` and `spec.privateKey` via [annotations on the `Ingress` resource](https://cert-manager.io/docs/usage/ingress/#supported-annotations). This should allow folks to configure ingress-shim `Certificate`s according to best practices (i.e by setting `Certificate`'s `spec.privateKey.rotationPolicy` to `Always`). In the future we would like to design a better mechanism to configure these `Certificate`s. We advise caution when using `Ingress` annotations as there is no validation of the annotations at `Ingress` creation time. ##### Contribution Workflow Over the past couple of months there have been a number of discussions in regards to contributor experience and project health, partially triggered by the awesome community discussions in cert-manager's KubeCon booth and also by the work done to move cert-manager to CNCF's incubating stage. For example, we've [clarified our feature policy](https://cert-manager.io/docs/contributing/policy/) and discussed the process of building cert-manager's [roadmap](https://github.com/cert-manager/cert-manager/blob/master/ROADMAP.md). If you're interested in these topics, we're happy to chat about them! ##### `make` Workflow cert-manager 1.8 introduced a new `make` based workflow alongside the existing Bazel workflow. The work to improve the `make` workflow was continued in 1.9 and our [contributor documentation](https://cert-manager.io/docs/contributing/building/) has been redefined to use `make` commands. This should make building and testing cert-manager easier with faster build and test times, easier debugging and less complexity. As part of this, Bazel has now been fully deprecated for building and testing cert-manager. As usual, we welcome any feedback in regards to further improving contributor experience. #### Thank You! Thank you to the following community members who had a merged PR for this version - your contributions are at the heart of everything we do! - [@AcidLeroy](https://github.com/AcidLeroy) - [@oGi4i](https://github.com/oGi4i) - [@spockz](https://github.com/spockz) (and [@yongk802](https://github.com/yongk802) who raised a similar PR) - [@andrewgkew](https://github.com/andrewgkew) - [@sveba](https://github.com/sveba) - [@rodrigorfk](https://github.com/rodrigorfk) - [@craigminihan](https://github.com/craigminihan) - [@lucacome](https://github.com/lucacome) - [@Dean-Coakley](https://github.com/Dean-Coakley) - [@Compy](https://github.com/Compy) Thanks also to the following maintainers who worked on cert-manager 1.9: - [@irbekrm](https://github.com/irbekrm) - [@SgtCoDFish](https://github.com/SgtCoDFish) - [@jakexks](https://github.com/jakexks) - [@wallrj](https://github.com/wallrj) - [@maelvls](https://github.com/maelvls) - [@JoshVanL](https://github.com/JoshVanL) - [@jahrlin](https://github.com/jahrlin) - [@munnerz](https://github.com/munnerz) #### Changes since v1.8.0 ##### Feature - Added support for pulling both AWS access key IDs and secret keys from Kubernetes secrets ([#5194](https://github.com/cert-manager/cert-manager/issues/5194), [@Compy](https://github.com/Compy)) - Adds `make clean-all` for starting a fresh development environment and `make which-go` for getting go version information when developing cert-manager ([#5118](https://github.com/cert-manager/cert-manager/issues/5118), [@SgtCoDFish](https://github.com/SgtCoDFish)) - Adds `make upload-release` target for publishing cert-manager releases to GCS, simplifying the cert-manager release process simpler and making it easier to change ([#5205](https://github.com/cert-manager/cert-manager/issues/5205), [@SgtCoDFish](https://github.com/SgtCoDFish)) - Adds a new alpha Prometheus summary vector metric `certmanager_http_venafi_client_request_duration_seconds` which allows tracking the latency of Venafi API calls. The metric is labelled by the type of API call. Example PromQL query: `certmanager_http_venafi_client_request_duration_seconds{api_call="request_certificate"}` will show the average latency of calls to the Venafi certificate request endpoint ([#5053](https://github.com/cert-manager/cert-manager/issues/5053), [@irbekrm](https://github.com/irbekrm)) - Adds more verbose logging info for certificate renewal in the DynamicSource webhook to include DNSNames ([#5142](https://github.com/cert-manager/cert-manager/issues/5142), [@AcidLeroy](https://github.com/AcidLeroy)) - Adds new LICENSES format and ability to verify and update licenses through make ([#5243](https://github.com/cert-manager/cert-manager/issues/5243), [@SgtCoDFish](https://github.com/SgtCoDFish)) - Adds private key Ingress annotations to set private key properties for Certificate ([#5239](https://github.com/cert-manager/cert-manager/issues/5239), [@oGi4i](https://github.com/oGi4i)) - Adds the `cert-manager.io/revision-history-limit` annotation for Ingress resources, to limit the number of CertificateRequests which are kept for a Certificate ([#5221](https://github.com/cert-manager/cert-manager/issues/5221), [@oGi4i](https://github.com/oGi4i)) - Adds the `literalSubject` field for Certificate resources. This is an alpha feature, enabled by passing the flag `--feature-gates=LiteralCertificateSubject=true` to the cert-manager controller and webhook. `literalSubject` allows fine-grained control of the subject a certificate should have when issued and is intended for power-users with specific use cases in mind ([#5002](https://github.com/cert-manager/cert-manager/issues/5002), [@spockz](https://github.com/spockz)) - Change default build dir from `bin` to `_bin`, which plays better with certain tools which might treat `bin` as just another source directory ([#5130](https://github.com/cert-manager/cert-manager/issues/5130), [@SgtCoDFish](https://github.com/SgtCoDFish)) - Helm: Adds a new `namespace` parameter which allows users to override the namespace in which resources will be created. This also allows users to set the namespace of the chart when using cert-manager as a sub chart. ([#5141](https://github.com/cert-manager/cert-manager/issues/5141), [@andrewgkew](https://github.com/andrewgkew)) - Helm: Allow for users to not auto-mount service account tokens [see also k/k#57601](https://github.com/kubernetes/kubernetes/issues/57601) ([#5016](https://github.com/cert-manager/cert-manager/issues/5016), [@sveba](https://github.com/sveba)) - Use multiple retries when provisioning tools using `curl`, to reduce flakes in tests and development environments ([#5272](https://github.com/cert-manager/cert-manager/issues/5272), [@SgtCoDFish](https://github.com/SgtCoDFish)) ##### Bug or Regression - CertificateRequests controllers must wait for the core secrets informer to be synced ([#5224](https://github.com/cert-manager/cert-manager/issues/5224), [@rodrigorfk](https://github.com/rodrigorfk)) - Ensure that `make release-artifacts` only builds unsigned artifacts as intended ([#5181](https://github.com/cert-manager/cert-manager/issues/5181), [@SgtCoDFish](https://github.com/SgtCoDFish)) - Ensure the startupapicheck is only scheduled on Linux nodes in the helm chart ([#5136](https://github.com/cert-manager/cert-manager/issues/5136), [@craigminihan](https://github.com/craigminihan)) - Fixed a bug where the Venafi Issuer would not verify its access token (TPP) or API key (Cloud) before becoming ready. Venafi Issuers now remotely verify the access token or API key ([#5212](https://github.com/cert-manager/cert-manager/issues/5212), [@jahrlin](https://github.com/jahrlin)) - Fixed release artifact archives generated by Make so that a leading `./` is stripped from paths. This ensures that behaviour is the same as v1.7 and earlier ([#5050](https://github.com/cert-manager/cert-manager/issues/5050), [@jahrlin](https://github.com/jahrlin)) - Increase timeouts for issuer and clusterissuer controllers to 2 minutes and increase ACME client HTTP timeouts to 90 seconds, in order to enable the use of slower ACME issuers which take a long time to process certain requests. ([#5226](https://github.com/cert-manager/cert-manager/issues/5226), [@SgtCoDFish](https://github.com/SgtCoDFish)) - Increases Venafi Issuer timeout for retrieving a certificate increased to 60 seconds, up from 10. This gives TPP…

The main reason for bumping Vault's version is because 1.2.3 is not compatible with the config parameter `disable_iss_validation`, which is needed for accommodating the future tests [1] that rely on bound tokens and static tokens. For context, Vault 1.2.3 was released on Sep 9, 2019 [2] but `disable_iss_validation` was only added on July 21st, 2020 in Vault 1.5.0. Due to a breaking change that happened in Vault 1.5.0 [3] in which Vault started loading the pod's token instead of using the same token (to be reviewed) for authenticating. An alternative solution could have been to prevent the service account from being mounted to the pod, but I figured that having the two service accounts separated is a better practice. [1]: cert-manager#5502 [2]: hashicorp/vault@c14bd9a2 [3]: https://github.com/hashicorp/vault/blob/main/CHANGELOG.md#150 Signed-off-by: Maël Valais <mael@vls.dev>

maelvls changed the title ~~the vault issuer can now be given a serviceAccountRef~~ The vault issuer can now be given a serviceAccountRef instead of relying on static service account tokens Oct 11, 2022

maelvls mentioned this pull request Oct 11, 2022

Vault: document the new field "serviceAccountRef" cert-manager/website#1081

Merged

maelvls marked this pull request as draft October 11, 2022 12:48

jetstack-bot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. labels Oct 11, 2022

maelvls force-pushed the projected-sa-vault branch from 48a13e8 to c794516 Compare November 25, 2022 11:10

jetstack-bot added size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. and removed needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. labels Nov 25, 2022

maelvls force-pushed the projected-sa-vault branch from c794516 to 7d2fbbf Compare November 25, 2022 11:24

maelvls mentioned this pull request Nov 25, 2022

End-to-end tests: use Vault 1.12.1 instead of the outdated Vault 1.2.3 #5604

Merged

jetstack-bot added size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. and removed size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. labels Nov 25, 2022

maelvls force-pushed the projected-sa-vault branch from 7d2fbbf to 1adc099 Compare November 25, 2022 18:54

maelvls force-pushed the projected-sa-vault branch from 1adc099 to 0936aca Compare December 2, 2022 14:48

maelvls force-pushed the projected-sa-vault branch from 4b27aca to 7a856af Compare February 7, 2023 12:26

cert-manager deleted a comment from jetstack-bot Feb 7, 2023

inteon reviewed Feb 7, 2023

View reviewed changes

internal/vault/vault.go Outdated Show resolved Hide resolved

inteon reviewed Feb 7, 2023

View reviewed changes

internal/vault/vault.go Show resolved Hide resolved

removed the unused "addVaultNamespaceToRequest"

5083b3e

I had mistakenly re-added this function in 76eef68. It had been removed in 6e05f43. Signed-off-by: Maël Valais <mael@vls.dev>

maelvls force-pushed the projected-sa-vault branch from abf7308 to 5083b3e Compare February 7, 2023 17:19

inteon approved these changes Feb 8, 2023

View reviewed changes

jetstack-bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 8, 2023

jetstack-bot assigned inteon Feb 8, 2023

jetstack-bot added the lgtm Indicates that a PR is ready to be merged. label Feb 8, 2023

jetstack-bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 9, 2023

jetstack-bot merged commit 2b48160 into cert-manager:master Feb 9, 2023

jetstack-bot added this to the v1.12 milestone Feb 9, 2023

maelvls deleted the projected-sa-vault branch February 9, 2023 13:55

This was referenced Feb 10, 2023

Add possibility to use ambient credentials for login to vault #4734

Closed

Service Account authentication to Vault #2345

Closed

Vault Service Account auth via ambient credentials #4733

Closed

tongpu mentioned this pull request May 23, 2023

feat(infra-apps): update cert-manager from 1.11.1 to 1.12.0 adfinis/helm-charts#1047

Merged

7 tasks

maelvls mentioned this pull request Sep 25, 2023

(Cluster)Issuer with vault auth and serviceAccountRef is not accepted by cluster due to audience #6150

Closed

andrey-dubnik mentioned this pull request Jan 26, 2024

Allow providing additional audiences with the k8s auth configuration #6666

Closed

terinjokes mentioned this pull request Oct 30, 2025

Include Vault hostname as default JWT audiences #8218

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

The vault issuer can now be given a serviceAccountRef instead of relying on static service account tokens#5502

The vault issuer can now be given a serviceAccountRef instead of relying on static service account tokens#5502
jetstack-bot merged 13 commits intocert-manager:masterfrom
maelvls:projected-sa-vault

maelvls commented Oct 11, 2022 •

edited

Loading

Uh oh!

maelvls commented Nov 30, 2022

Uh oh!

Uh oh!

Uh oh!

inteon left a comment

Uh oh!

jetstack-bot commented Feb 8, 2023

Uh oh!

maelvls commented Feb 9, 2023

Uh oh!

maelvls commented Feb 10, 2023

Uh oh!

TheFutonEng commented Feb 21, 2023

Uh oh!

maelvls commented Mar 10, 2023

Uh oh!

paulcostinean commented Apr 3, 2023 •

edited

Loading

Uh oh!

Garagoth commented Jun 7, 2023 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

Conversation

maelvls commented Oct 11, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

maelvls commented Nov 30, 2022

Uh oh!

Uh oh!

Uh oh!

inteon left a comment

Choose a reason for hiding this comment

Uh oh!

jetstack-bot commented Feb 8, 2023

Uh oh!

maelvls commented Feb 9, 2023

Uh oh!

maelvls commented Feb 10, 2023

Uh oh!

TheFutonEng commented Feb 21, 2023

Uh oh!

maelvls commented Mar 10, 2023

Uh oh!

paulcostinean commented Apr 3, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Garagoth commented Jun 7, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

maelvls commented Oct 11, 2022 •

edited

Loading

paulcostinean commented Apr 3, 2023 •

edited

Loading

Garagoth commented Jun 7, 2023 •

edited

Loading