-
Notifications
You must be signed in to change notification settings - Fork 316
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
[EKS] [BUG]: CSR is not returning the certificate after approval in 1.21 #1604
Comments
Same issue here. Any traction on a resolution? |
any updates here? |
I also encounter this issue.. |
After a few hours of trying to figure out what's going on, I found this open issue. Could you please share any updates? |
By design EKS does not issue certificates for CSRs with signerName "kubernetes.io/kubelet-serving" unless the CSR was actually requested by a kubelet. EKS's custom signer validates this by checking that the requested SANs for CSRs with signerName If you need a certificate for a non-kubelet application, for 1.21 and below use CSR v1beta1 API and signerName |
@mikestef9 does EKS support a signer name of |
@mikestef9 with 1.22 out, I didn’t see that procedure in the blog post by @chris-short |
This is now covered in our documentation https://docs.aws.amazon.com/eks/latest/userguide/cert-signing.html. I will leave this issue open for a little while to make sure what we included in v1.22 launch meets the needs outlined in this issue. |
@mikestef9 is there a docs page which mentions which signers are supported? I checked |
Can you clarify what you mean by which signers. From the doc, this is signer name we support
|
@mikestef9 so in upstream Kubernetes there are a number of in-built signers as detailed here I'm looking at one of these Looking at the EKS docs, I can't see a definitive list of supported signers, so I'm not sure if the behaviour I'm seeing is a bug or working as intended. This is a quick screenshot of what I'm seeing on EKS the cert is approved ok, but never issued. |
I found the same issue on k8s 1.21 using The output from
|
@mikestef9, this breaks virtual-kubelet implementations that want to support kubectl logs/exec via the vk controller, where the CSR must be signed by kubelet-serving for the vk controller pod IP. Is there any way we could relax this design constraint? Or is there another way I could get a certificate trusted by the API server for kubelet serving? |
I found the same issue on eks v1.19.15-eks-9c63c4 , v1.20.11-eks-f17b81 using kubernetes.io/kube-apiserver-client as a signer name. |
For CSRs with But what signer to use for CSRs with |
I'm the same boat with |
- There's no need for creating a mTLS keypair based on a k8s CSR - Will fix known EKS issue aws/containers-roadmap#1604 by generating a self-signed certificate directly by operator that will be trusted by MinIO and KES for mTLS authentication Signed-off-by: Lenin Alevski <alevsk.8772@gmail.com>
- There's no need for creating a mTLS keypair based on a k8s CSR - Will fix known EKS issue aws/containers-roadmap#1604 by generating a self-signed certificate directly by operator that will be trusted by MinIO and KES for mTLS authentication Signed-off-by: Lenin Alevski <alevsk.8772@gmail.com>
- There's no need for creating a mTLS keypair based on a k8s CSR - Will fix known EKS issue aws/containers-roadmap#1604 by generating a self-signed certificate directly by operator that will be trusted by MinIO and KES for mTLS authentication - Adding documentation for `operator-ca-tls` and MinIO Operator upgrades Signed-off-by: Lenin Alevski <alevsk.8772@gmail.com>
- There's no need for creating a mTLS keypair based on a k8s CSR - Will fix known EKS issue aws/containers-roadmap#1604 by generating a self-signed certificate directly by operator that will be trusted by MinIO and KES for mTLS authentication - Adding documentation for `operator-ca-tls` and MinIO Operator upgrades Signed-off-by: Lenin Alevski <alevsk.8772@gmail.com>
I'm having the same question: does eks support |
I'm having a similar problem with Kubelet CSR's in EKS... I have some EKS clusters in 1.21 and 1.22 versions and some Kubelets started to request by CSR but many CSRs stood in pending or approved state and few CSRs with approved and issued state. The hostname-type is the same for LaunchTemplate and Subnets with IP Name type matching with SAN DNS and IP. All these CSRs are requested by real Kubelets and fails when ControlPlane or other tools try to comunicate with Kubelet in default TLS port. Even with hostname type ip-name doesn't work :( Some idea why in a few worker nodes works? |
We are running into this as well. We need client auth support for OPA admission controller webhooks. Do we have an actual issue to track |
We are also running into this issue because we need
Any workaround available? |
Following the AWS Certificate Signing Instructions does indeed work when following the Standalone Vault TLS guide with the following caveats.
And here's some sample output demonstrating that it worked:
|
If you're using EKS on Fargate, check your cluster role if its trust relationship allows AssumeRole for "eks.amazonaws.com". |
The documentation provided https://docs.aws.amazon.com/eks/latest/userguide/cert-signing.html works to have an approved, issued CSR. But existing deployed mutatingwebhook configuration has started throwing following errors: CSR was applied via local user having admin access. Kubectl Version: Error message: Anybody else encountering similar issues? The current CA bundle points to eks cluster certificate authority. what should be the right config here? #Update 1: |
And still, what about client auth? Is there any way to auth as a client in EKS cluster without IAM(and aws-cli on a local host)? Currently I can't auth using just plain client certificates, because I was unable to sign them. |
EKS currently does not support Kubelet client auth, hence we do not currently sign client certificates. |
"EKS currently does not support Kubelet client auth, hence we do not currently sign client certificates." Would save a lot of people a lot of trouble if that line was right at the top of the docs. |
May I ask @mikestef9 why this design choise? Parting from Kubernetes standard just causes issues to users and in our case I did spent quite a few hours to figure out why a previously working subsystem suddenly broke. Also having to use |
Community Note
Description
This is a potential bug, as a) it doesn't match the service expectations; b) it doesn't happen with any previous EKS version; c) it works as expected on other, non-EKS 1.21s.
Essentially, upon submitting a Certificate Signing Request, EKS 1.21 is returning success but not including the certificate in the CSR's
.status.certificate
field. To reproduce please try to run:The issue was discovered and documented in detail as part of the StackGres project. Please refer to the issue there for completeness.
The text was updated successfully, but these errors were encountered: