forked from cert-manager/cert-manager
-
Notifications
You must be signed in to change notification settings - Fork 0
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
pull
wants to merge
1,887
commits into
next-stack:master
Choose a base branch
from
cert-manager:master
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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]>
Signed-off-by: cert-manager-bot <[email protected]>
Signed-off-by: Ashley Davis <[email protected]>
Signed-off-by: Ashley Davis <[email protected]>
[CI] Merge self-upgrade-master into master
Signed-off-by: harshitasao <[email protected]>
Signed-off-by: Richard Wall <[email protected]>
Signed-off-by: Richard Wall <[email protected]>
Signed-off-by: Richard Wall <[email protected]>
Signed-off-by: Ashley Davis <[email protected]>
Signed-off-by: harshitasao <[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]>
Signed-off-by: Adrian Lai <[email protected]>
Signed-off-by: Adrian Lai <[email protected]>
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]>
Signed-off-by: Miguel Varela Ramos <[email protected]>
Signed-off-by: Miguel Varela Ramos <[email protected]>
Signed-off-by: Miguel Varela Ramos <[email protected]>
Signed-off-by: Bartosz Slawianowski <[email protected]>
Signed-off-by: Miguel Varela Ramos <[email protected]>
Signed-off-by: cert-manager-bot <[email protected]>
Signed-off-by: Tim Ramlot <[email protected]>
Signed-off-by: Adolfo García Veytia (puerco) <[email protected]>
Chart docs: Add enableGatewayAPI feature gates
Use new go 1.23 iterators
Signed-off-by: Adam Talbot <[email protected]>
…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]>
Signed-off-by: Tim Ramlot <[email protected]>
Signed-off-by: Tim Ramlot <[email protected]>
Signed-off-by: Tim Ramlot <[email protected]>
[CI] Self-upgrade merging self-upgrade-master into master
Signed-off-by: Ashley Davis <[email protected]>
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
Remove unused test functions
Signed-off-by: Ashley Davis <[email protected]>
Signed-off-by: Ashley Davis <[email protected]>
Signed-off-by: Ashley Davis <[email protected]>
Cleanup key gen / RSA key sizes
Signed-off-by: cert-manager-bot <[email protected]>
[CI] Merge self-upgrade-master into master
Signed-off-by: Jochen Richter <[email protected]>
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]>
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )