Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Post-Release] Merge release-next into master #1230

Closed
wants to merge 35 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
35 commits
Select commit Hold shift + click to select a range
0b5d7e2
Merge pull request #1189 from cert-manager/master
jetstack-bot Feb 21, 2023
1d838a8
vault: document the new field "serviceAccountRef"
maelvls Sep 30, 2022
ab117a7
serviceAccountRef: address Richard's comments
maelvls Feb 21, 2023
803891f
serviceAccoutRef: PR review suggestions
maelvls Feb 27, 2023
46cdf9c
serviceAccoutRef: PR review suggestions
maelvls Feb 27, 2023
dcef301
serviceAccountRef: add a release-note page for v1.12
maelvls Feb 27, 2023
c399aae
package.json: use "npm exec" for running the "concurrently" tool
maelvls Feb 27, 2023
fe91700
fix dead link
maelvls Feb 27, 2023
32a3e8b
Revert "package.json: use "npm exec" for running the "concurrently" t…
maelvls Mar 7, 2023
d3c9fc6
Merge pull request #1081 from maelvls/document-vault-bound-serviceacc…
jetstack-bot Mar 7, 2023
09fd33b
ingressClassName: swap the "class" for the "ingressClassName"
maelvls Mar 7, 2023
66cd7eb
guide: fix incorrect fields "ingress" and "ingressClass"
maelvls Mar 7, 2023
a1dfb91
update the http01 does with ingressClassName
maelvls Mar 7, 2023
aa00c3c
add a mention in the release notes
maelvls Mar 7, 2023
ef98aec
ingressClassName: update the API reference documentation
maelvls Mar 9, 2023
2b69ad6
ingressClassName: re-add the ingress-class-compatibility page
maelvls Mar 9, 2023
ab1b9da
ingressClassName: add div and icon
maelvls Mar 27, 2023
33bdb94
ingressClassName: consistent warning using quote block
maelvls Mar 27, 2023
4de800f
ingressClassName: address PR comments
maelvls Mar 27, 2023
0b99aa0
ingressClassName: move the warning to below the sections
maelvls Mar 27, 2023
0bb1720
Merge pull request #1196 from maelvls/ingressclassname
jetstack-bot Mar 31, 2023
2e2a425
write the release notes for 1.12
maelvls May 5, 2023
f69c9da
release-notes: add the latest changes to the release notes for 1.12
maelvls May 9, 2023
9fe0b57
Add a release note for memory improvements
irbekrm May 16, 2023
ed440d3
release-notes-1.12: talk about the go.mod changes
maelvls May 16, 2023
6ca15f0
use the official typography for VCert (instead of vCert)
maelvls May 16, 2023
444b74f
turn commit-like release notes into release notes
maelvls May 16, 2023
f75ba88
rephrase the section about CVEs and Go modules
maelvls May 16, 2023
68ba755
edit more release notes to make them user-friendly
maelvls May 16, 2023
26aa94d
release-notes-1.12: address feedback
maelvls May 19, 2023
2879046
release-notes: add links to documentation, PRs and designs
maelvls May 19, 2023
df01bd8
release-notes: transform PR numbers and GitHub handles into links
maelvls May 19, 2023
e43ed15
release-notes: copy the "thank you" section from the GitHub release
maelvls May 19, 2023
5835a2e
release-notes: fix spelling
maelvls May 19, 2023
efd9872
Merge pull request #1220 from maelvls/release-notes-1.12
jetstack-bot May 19, 2023
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 35 additions & 1 deletion .spelling
Original file line number Diff line number Diff line change
Expand Up @@ -475,13 +475,15 @@ v1.8.2
v1.9.0
v1.9.1
v1.10
v1.11.0
v1.12.0
v1alpha1
v1alpha2
v1alpha3
v1beta1
v2
v3
vCert
VCert
vendoring
vendored
versioning
Expand Down Expand Up @@ -553,6 +555,38 @@ NetworkPolicy
mjudeikis
rgl
1password
secretless
TokenRequest
v1.12.0
v1.12.0.
PodDisruptionBudgets
andrewsomething
avi-08
e96wic
ExNG
g-gaston
jkroepke
malovme
maumontesilva
tobotg
TrilokGeer
waterfoul
yulng
vidarno
vinzent
dsonck92
go.work
go.mod
validatingwebhookconfigurations
mutatingwebhookconfigurations
customresourcedefinitions
unlabelled
v1.27.1
v0.6.0.
v4.4.1
liveness
apiservices
arm64

# TEMPORARY
# these are temporarily ignored because the spellchecker
Expand Down
7 changes: 4 additions & 3 deletions content/docs/configuration/acme/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -65,7 +65,7 @@ spec:
solvers:
- http01:
ingress:
class: nginx
ingressClassName: nginx
```

Solvers come in the form of [`dns01`](./dns01/README.md) and
Expand Down Expand Up @@ -123,8 +123,9 @@ spec:
solvers:
- http01:
ingress:
class: nginx
ingressClassName: nginx
```

> Note: cert-manager versions pre-`v1.3.0` also required users to specify the
> MAC algorithm for EAB by setting
> `Issuer.spec.acme.externalAccountBinding.keyAlgorithm` field. This field is
Expand Down Expand Up @@ -296,7 +297,7 @@ spec:
solvers:
- http01:
ingress:
class: nginx
ingressClassName: nginx
selector:
matchLabels:
"use-http01-solver": "true"
Expand Down
44 changes: 34 additions & 10 deletions content/docs/configuration/acme/http01/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -43,7 +43,7 @@ spec:
solvers:
- http01:
ingress:
class: nginx
ingressClassName: nginx
```

## Options
Expand All @@ -52,18 +52,32 @@ The HTTP01 Issuer supports a number of additional options. For full details on
the range of options available, read the [reference
documentation](../../../reference/api-docs.md#acme.cert-manager.io/v1.ACMEChallengeSolverHTTP01).

### `class`
### `ingressClassName`

<div className="info">

If the `class` field is specified, cert-manager will create new `Ingress`
resources in order to route traffic to the `acmesolver` pods, which are
responsible for responding to ACME challenge validation requests.
📌 The field `ingressClassName` was added in cert-manager 1.12.

If this field is not specified, and `name` is also not specified,
cert-manager will default to create *new* `Ingress` resources but will **not**
set the ingress class on these resources, meaning *all* ingress controllers
installed in your cluster will serve traffic for the challenge solver,
potentially incurring additional cost.
</div>

If the `ingressClassName` field is specified, cert-manager will create new
`Ingress` resources in order to route traffic to the `acmesolver` pods, which
are responsible for responding to ACME challenge validation requests.

This is the recommended way of configuring the Ingress controller. Most Ingress
controllers support `ingressClassName`, with the notable exception of
ingress-gce (as per the page [Configure Ingress for external load
balancing](https://cloud.google.com/kubernetes-engine/docs/how-to/load-balance-ingress)).

### `class`

If the `class` field is specified, a new Ingress resource with a randomly
generated name will be created in order to solve the challenge. This new
resource will have an annotation with key `kubernetes.io/ingress.class` and
value set to the value of the `class` field.

This field is only recommended with ingress-gce. ingress-gce [doesn't support the
`ingressClassName` field](https://cloud.google.com/kubernetes-engine/docs/how-to/load-balance-ingress).

### `name`

Expand All @@ -77,6 +91,16 @@ This mode should be avoided when using ingress controllers that expose a single
IP for all ingress resources, as it can create compatibility problems with
certain ingress-controller specific annotations.

<div className="warning">

If `class` and `ingressClassName` are not specified, and `name` is also not
specified, cert-manager will default to create *new* `Ingress` resources but
will **not** set the ingress class on these resources, meaning *all* ingress
controllers installed in your cluster will serve traffic for the challenge
solver, potentially incurring additional cost.

</div>

<h3 id="ingress-service-type">`serviceType`</h3>

In rare cases it might be not possible/desired to use `NodePort` as type for the
Expand Down
122 changes: 117 additions & 5 deletions content/docs/configuration/vault.md
Original file line number Diff line number Diff line change
Expand Up @@ -144,13 +144,125 @@ spec:
key: token
```

<a id="authenticating-with-kubernetes-service-accounts"></a>

### Authenticating with Kubernetes Service Accounts

Vault can be configured so that applications can authenticate using Kubernetes
[`Service Account
Tokens`](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin).
You find documentation on how to configure Vault to authenticate using Service
Account Tokens [here](https://www.vaultproject.io/docs/auth/kubernetes.html).
The [Vault Kubernetes
Auth](https://developer.hashicorp.com/vault/docs/auth/kubernetes) allows
cert-manager to authenticate to Vault using a Kubernetes Service Account Token
in order to issue certificates using Vault as a certification authority. The
Kubernetes service account token can be provided in two ways:

- [Secretless Authentication with a Service Account](#secretless-authentication-with-a-service-account) (recommended),
- [Authentication with a Static Service Account Token](#static-service-account-token).

#### Secretless Authentication with a Service Account

ℹ️ This feature is available in cert-manager >= v1.12.0.

With the secretless authentication with a service account, cert-manager creates
an ephemeral service account token using the TokenRequest API and uses it to
authenticate with Vault. These tokens are short-lived (10 minutes) and are
never stored to disk.

This is the recommended authentication method because it does not rely on the
deprecated static service account tokens. The static service account tokens pose
a threat due to their infinite lifetime. Static service account tokens have been
disabled by default on Kubernetes 1.24.

The first step is to create a `ServiceAccount` resource:

```sh
kubectl create serviceaccount -n sandbox vault-issuer
```

Then add an RBAC Role so that cert-manager can get tokens for the
ServiceAccount:

```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: vault-issuer
namespace: sandbox
rules:
- apiGroups: ['']
resources: ['serviceaccounts/token']
resourceNames: ['vault-issuer']
verbs: ['create']
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: vault-issuer
namespace: sandbox
subjects:
- kind: ServiceAccount
name: cert-manager
namespace: cert-manager
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: vault-issuer
```

Finally, create the Issuer resource:

```yaml
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: vault-issuer
namespace: sandbox
spec:
vault:
path: pki_int/sign/example-dot-com
server: https://vault.local
auth:
kubernetes:
role: my-app-1
mountPath: /v1/auth/kubernetes
serviceAccountRef:
name: vault-issuer
```

> **Issuer vs. ClusterIssuer:** With an Issuer resource, you can only refer to a
> service account located in the same namespace as the Issuer. With a
> ClusterIssuer, the service account must be located in the namespace that is
> configured by the flag `--cluster-resource-namespace`.

To create the role in Vault, you can use the following command:

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

It is recommended to use a different Vault role each per Issuer or
ClusterIssuer. The `audience` allows you to restrict the Vault role to a single
Issuer or ClusterIssuer. The syntax is the following:

```yaml
"vault://<namespace>/<issuer-name>" # For an Issuer.
"vault://<cluster-issuer-name>" # For a ClusterIssuer.
```

The expiration duration for the Kubernetes tokens that are requested is
hard-coded to 10 minutes (that's the minimum accepted). The `ttl` field can be
as short as possible, since cert-manager requests a new token every time it
needs to talks to Vault.

Although it is not recommended, you can also use the same Vault role for all of
your Issuers and ClusterIssuers by omitting the `audience` field and re-using
the same service account.
<a name="static-service-account-token"></a>

#### Authentication with a Static Service Account Token

For the Vault issuer to use this authentication, cert-manager must get access to
the token that is stored in a Kubernetes `Secret`. Kubernetes Service Account
Expand Down
25 changes: 18 additions & 7 deletions content/docs/installation/upgrading/ingress-class-compatibility.md
Original file line number Diff line number Diff line change
@@ -1,12 +1,21 @@
---
title: Notes on Ingress Class Compatibility
title: Notes on the breaking change with the `class` field that happened in cert-manager v1.5.4
description: 'cert-manager installation: Notes on ingress classes and safe upgrades'
---

In cert-manager v1.5.4 we made a change to the HTTP-01 code which was not backwards compatible.
See [Regression: HTTP-01 challenges fail with Istio, Traefik, ingress-gce and Azure AGIC].

[Regression: HTTP-01 challenges fail with Istio, Traefik, ingress-gce and Azure AGIC]: https://github.com/cert-manager/cert-manager/issues/4537
> ⚠️ This document focuses on the `class` field of the Issuer and ClusterIssuer
> resources and the annotation `kubernetes.io/ingress.class`. If you are
> interested in using `ingressClassName` on your Ingress resources when using
> cert-manager's HTTP-01 solver, see the page [Securing Ingress
> Resources](../../configuration/acme/http01#ingressclassname).

In cert-manager v1.5.4 we made a change to the HTTP-01 code which was not
backwards compatible. Before v1.5.4, cert-manager was using the `class` field on
the Issuer and ClusterIssuer to add the annotation
`kubernetes.io/ingress.class`. In cert-manager v1.5.4, cert-manager stopped
setting the annotation. See [Regression: HTTP-01 challenges fail with Istio,
Traefik, ingress-gce and Azure AGIC].

In v1.5.5, v1.6.2 and 1.7.1 we fixed this problem.

Expand All @@ -18,6 +27,8 @@ If you have cert-manager v1.5.3 (or below) you should skip v1.5.4 and instead:

and you can ignore the rest of this document.

[Regression: HTTP-01 challenges fail with Istio, Traefik, ingress-gce and Azure AGIC]: https://github.com/cert-manager/cert-manager/issues/4537

The following notes apply to anyone upgrading from cert-manager v1.5.4, v1.6.0, v1.6.1 on Kubernetes v1.19 or later.

# Background
Expand Down Expand Up @@ -49,9 +60,9 @@ compatibility is to only use the annotation, even when creating `v1` Ingresses.

## ingress-nginx

If you chose not to use the IngressClass `nginx` that is created by default by the Helm chart
(e.g., you named the IngressClass `nginx-outside`), you will need to add the flags
`--ingress-class` and `--ingress-class-by-name` to your ingress-nginx deployment:
If you chose not to use the IngressClass `nginx` that is created by default by
the Helm chart (e.g., you named the IngressClass `nginx-outside`), you will need
to add the flags `--ingress-class` to your ingress-nginx deployment:

```
--ingress-class=nginx-outside --ingress-class-by-name=true
Expand Down
4 changes: 2 additions & 2 deletions content/docs/installation/upgrading/upgrading-0.7-0.8.md
Original file line number Diff line number Diff line change
Expand Up @@ -78,7 +78,7 @@ spec:
- selector: {}
http01:
ingress:
class: nginx
ingressClassName: nginx
- selector:
# Any Certificate resources, or Ingress resources that use
# ingress-shim and match the below label selector will use this
Expand Down Expand Up @@ -204,7 +204,7 @@ spec:
- selector: {}
http01:
ingress:
class: nginx
ingressClassName: nginx
- selector:
# Any Certificate resources, or Ingress resources that use
# ingress-shim and match the below label selector will use this
Expand Down
Loading