Closed dalgibbard closed 2 weeks ago
/transfer kubernetes
/sig auth
/triage accepted
I do not believe we could change the implicit default of this flag as that would be a backwards incompatible change (we have no way of knowing if clients support TLS 1.3 in a particular env). I could see us removing the default of the flag altogether and requiring that it be specified. The documentation could then recommend 1.3 for environments where it is known to be supported, and 1.2 for environments where compatibility is desired over maximum security.
I would recommend bringing this up during a SIG Auth and API machinery biweekly meeting before taking any further action.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
/area security ?
This issue has not been updated in over 1 year, and should be re-triaged.
You can:
/triage accepted
(org members only)/close
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/
/remove-triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
Hi all, In relation to: https://github.com/kubernetes-sigs/metrics-server/issues/985
Given that pretty much all libraries/clients out there have supported TLS1.3 for quite a while now, it would be great to move towards deprecating TLS1.2 and lower -- this removes the need to employ Server-side Ciper ordering, and/or enabling/disabling various ciphers which are deemed insecure (ie. 3DES, CBC); mitigating potential issues like GOLDENDOODLE / SWEET32 / LUCKY13 for all clients.
Thanks in advance!