Previously it wasn't possible to set a custom CA bundle for an ACME
server, leading users to either patch the cert-manager system CA bundle
manually or else use SkipTLSVerify which is a security issue.
This adds CABundle for ACME, similar to what we have for Vault and
Venafi TPP issuers.
Longer term we'd like to have a more fully featured approach. It would
for example make sense to support loading CA bundles from ConfigMaps or
Secrets (similar to what we do for Vault issuers today), but for now this
change is the simplest change.
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
Clarifies language a little; makes it clearer that the bundle
should be base64 encoded. Previously it was slightly confusing
in that PEM certificates are themselves base64 encoded.
Also makes it clearer what our CABundle validation does and does not do
by adding a standalone validation function and tweaking the error
message for an invalid CA bundle.
Also updates validation to not print CA bundle for Vault issuer when the
bundle is invalid, since it won't help with debugging anything.
Currently the bundle is printed as byte values ("0x32, 0x58, 0x43...")
and in any case printing the whole bundle could be noisy if it's large
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
```text
{
"VulnerabilityID": "CVE-2022-41717",
"PkgName": "golang.org/x/net",
"InstalledVersion": "v0.0.0-20220921155015-db77216a4ee9",
"FixedVersion": "0.4.0",
"Layer": {
"DiffID": "sha256:629212d4fb1b47585329d1c630cb91f919ddcd6168031a07121953d6c6dbd438"
},
"PrimaryURL": "https://avd.aquasec.com/nvd/cve-2022-41717",
"DataSource": {
"ID": "go-vulndb",
"Name": "The Go Vulnerability Database",
"URL": "https://github.com/golang/vulndb"
},
"Title": "An attacker can cause excessive memory growth in a Go server accepting ...",
"Description": "An attacker can cause excessive memory growth in a Go server accepting HTTP/2 requests. HTTP/2 server connections contain a cache of HTTP header keys sent by the client. While the total number of entries in this cache is capped, an attacker sending very large keys can cause the server to allocate approximately 64 MiB per open connection.",
"Severity": "UNKNOWN",
"References": [
"https://go.dev/cl/455635",
"https://go.dev/cl/455717",
"https://go.dev/issue/56350",
"https://groups.google.com/g/golang-announce/c/L_3rmdT0BMU/m/yZDrXjIiBQAJ",
"https://pkg.go.dev/vuln/GO-2022-1144"
],
"PublishedDate": "2022-12-08T20:15:00Z",
"LastModifiedDate": "2022-12-08T22:30:00Z"
}
```
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
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]: https://github.com/cert-manager/cert-manager/pull/5502
[2]: https://github.com/hashicorp/vault/commit/c14bd9a2
[3]: https://github.com/hashicorp/vault/blob/main/CHANGELOG.md#150
Signed-off-by: Maël Valais <mael@vls.dev>
This avoids a race condition with the `release-manifests` and
`release-manifests-signed` targets.
When running in parallel, one could execute `rm -rf
$(BINDIR)/scratch/manifests` while the other was running.
This could also conceivably have led to incorrectly packaged
manifests when both were run in parallel.
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
