Previously, the Vault issuer was only able to use a Secret in order to
use the "Kubernetes authentication" method. The downside to this service
account Secret token is that it has the default JWT iss
"kubernetes/serviceaccount" (along with the fact that the token is not
bound to a particular pod and has no expiry).
With the new serviceAccountRef, cert-manager now requests the token on
behalf of the pod in order to authenticate with Vault.
Signed-off-by: Maël Valais <mael@vls.dev>
Vault distributions like "Bank Vaults" automatically configure
and provision Vault and provide the CA bundle via a Kubernetes
Secret. Having to hard-code the bundle in the Issuer instead
of dynamically referencing it through the Secret requires
a manual second step when using a GitOps workflow.
Signed-off-by: Nils Mueller <nm@impactful.it>
This removes all .bazel and .bzl files, and a bunch of scripts relating
to bazel, now that it's been entirely replaced.
There are still a few places where traces could be removed, but this
removes the brunt of the bazel stuff that remains.
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
This change adds the ability to express certificate duration using
the Kubernetes CSR spec.expirationSeconds field alongside the existing
approach of using the experimental.cert-manager.io/request-duration
annotation. Both approaches are supported as the expirationSeconds
field requires Kubernetes v1.22+.
Signed-off-by: Monis Khan <mok@vmware.com>
DER Format to create key.der binary format of the private key.
CombinedPEM Format to create tls-combined.pem containing tls.key + tls.crt.
Added Unit and e2e tests for secret with Additional output format.
Feature flag AdditionalCertificateOutputFormats to enable feature.
Signed-off-by: Thierry Sallé <seuf76@gmail.com>
Note that using ed25519 on the public internet is not currently
recommended, since it's not widely supported. You'd likely not be able
to use an Ed25519 cert with an ACME issuer today.
Ed25519 certs might be useful for internal PKI, though - an ed25519 CA
issuer, say - or for testing ed25519 certs before they become more
widely available on the public internet. They're not currently
supported by Vault, Venafi or ACME (Letsencrypt) issuers.
Signed-off-by: Anner J. Bonilla <abonilla@hoyosintegrity.com>
Signed-off-by: Anner J. Bonilla <annerjb@gmail.com>
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
The log message:
multiple CertificateRequests found for the 'next' revision 2,
skipping issuance until no more duplicate.
can be better phrased as:
multiple CertificateRequests are found for the 'next' revision 2,
issuance is skipped until there are no more duplicates.
Signed-off-by: Maël Valais <mael@vls.dev>
Co-authored-by: Josh Soref <jsoref@users.noreply.github.com>
