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

[pull] master from cert-manager:master #1066

Open
wants to merge 1,887 commits into
base: master
Choose a base branch
from

Conversation

pull[bot]
Copy link

@pull pull bot commented Oct 28, 2022

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

@pull pull bot added the ⤵️ pull label Oct 28, 2022
jrcichra and others added 29 commits July 3, 2024 17:54
When tracking down unowned secrets in a cluster, I noticed secret/cert-manager-webhook-ca does not specify app.kubernetes.io/managed-by.

This label is useful when filtering out managed Secrets in a multi-tenant cluster to generate reports or alerts.

Helm applies this label to resources it manages.

Set the string to "cert-manager" since it is responsible for generating and regenerating the CA.

https://kubernetes.io/docs/reference/labels-annotations-taints/#app-kubernetes-io-managed-by

Signed-off-by: Justin Cichra <[email protected]>
[CI] Merge self-upgrade-master into master
Signed-off-by: Richard Wall <[email protected]>
Signed-off-by: Ashley Davis <[email protected]>
Reduce memory usage by only caching the metadata of Secret resources
BUGFIX: AWS route53: Set global region for sts
This allows configuration of the http01 solver PodSecurityContext as
part of the Issuer specification.

Signed-off-by: Adrian Lai <[email protected]>
Signed-off-by: Adrian Lai <[email protected]>
These were copy-pasted in from the parent definitions. We don't marshal
to protobuf (none of the other structs have equivalent annotations), so
remove them as they are unnecessary.

Signed-off-by: Adrian Lai <[email protected]>
Signed-off-by: Bartosz Slawianowski <[email protected]>
puerco and others added 30 commits October 9, 2024 14:57
Signed-off-by: Adolfo García Veytia (puerco) <[email protected]>
Chart docs: Add enableGatewayAPI feature gates
…eated when a certificate is deleted

Signed-off-by: Adam Talbot <[email protected]>
…te-requests-while-being-deleted

fix: don't create certificaterequests while being deleted
Signed-off-by: Tim Ramlot <[email protected]>
[CI] Self-upgrade merging self-upgrade-master into master
add IPv6 example for recursive DNS arg
See also #7357

A US DoD document [1] states that:

> Effective immediately, all Public Key enabled commercial-off-the-shelf
> software and Public Key enabled Open-Source software integrations [...]
> must support at least RSA-3072 (4096 is preferred) and SHA-384.

cert-manager already supports large RSA keys - that's no problem. But we
always use SHA256 with all RSA keys currently; this commit changes that
so we use SHA512 for RSA keys 4096 bits and above, or else SHA384 for
RSA keys 3072 bits and above, or else SHA256.

We discussed in standups / in the issue how to roll this out, and the
consensus so far has been to roll this out unilaterally. Albeit we don't
have data to support our assumption, we believe there won't be
any huge compatibility problems from using this approach.

One potential issue is that SHA512 can take (much) longer on some low
powered 32-bit platforms (think older Raspberry Pis). We decided that
the risk of slowdown there isn't worth delaying the rollout of this.
Plus, people using those devices always have the option of using
RSA-2048 or else ECDSA / Ed25519.

[1]: https://dl.dod.cyber.mil/wp-content/uploads/pki-pke/pdf/unclass-memo_dodcryptoalgorithms.pdf

Signed-off-by: Ashley Davis <[email protected]>
Use different hash algorithms for larger RSA keys
Cleanup key gen / RSA key sizes
[CI] Merge self-upgrade-master into master
Signed-off-by: Ashley Davis <[email protected]>
add tenantID option to azureDNS managedIdentity
Resources with applyset labels will be pruned, which is problematic.

Instead of a generic annotation to control label propagation, the
applyset labels are always excluded. This should be a good middleground
whilst an API for doing this in a more generic way is discussed. The
label should not ever be propagated, and so is a safe default.

Fixes: #7306

Signed-off-by: Thomas Way <[email protected]>
Do not propagate applyset labels
Includes a lot of comments explaining how the maxima were calculated.
This is _very_ conservative, and assumes we're dealing with RSA keys
twice the size of what we actually allow as a maximum.

From running the included benchmark it seems the pathological runtime is
about 13617196ns (13ms) on an M2 Max which seems acceptable.

Signed-off-by: Ashley Davis <[email protected]>
Restrict max size of PEM inputs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.