We're facing an issue that was reported before as part of another issue (https://github.com/awslabs/amazon-eks-ami/issues/244#issuecomment-494812417) but since the original issue was about something different which is fixed by now I'm extracting this into a new one.
What happened:
Certificates generated using the cluster signer are missing the request SANs. Just following the example steps from https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/ will show this behavior:
CSR:
Name: my-svc.my-namespace
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"certificates.k8s.io/v1beta1","kind":"CertificateSigningRequest","metadata":{"annotations":{},"name":"my-svc.my-namespace"},"spec":{"request":"LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTU
lJQllqQ0NBUWdDQVFBd01ERXVNQ3dHQTFVRUF4TWxiWGt0Y0c5a0xtMTVMVzVoYldWemNHRmpaUzV3YjJRdQpZMngxYzNSbGNpNXNiMk5oYkRCWk1CTUdCeXFHU000OUFnRUdDQ3FHU000OUF3RUhBMElBQkEwbHFpRVZZNTJLCmV1SjdTMlRDQU8rai9QcVJ2aVVPV3VMVkQxbEhPcnpvT1A5OFh5Kyt4aE92N0I3Q2c5bUxWMmNCN1Z4NFJnT3kKL2dtZFhkd1Rp
bGFnZGpCMEJna3Foa2lHOXcwQkNRNHhaekJsTUdNR0ExVWRFUVJjTUZxQ0pXMTVMWE4yWXk1dAplUzF1WVcxbGMzQmhZMlV1YzNaakxtTnNkWE4wWlhJdWJHOWpZV3lDSlcxNUxYQnZaQzV0ZVMxdVlXMWxjM0JoClkyVXVjRzlrTG1Oc2RYTjBaWEl1Ykc5allXeUhCTUFBQWhpSEJBb0FJZ0l3Q2dZSUtvWkl6ajBFQXdJRFNBQXcKUlFJZ2NHZHMvcVExc0IzVG
9ENXI5dFdzQW1aZmdwY1hPZGs5NFJ1dVhDTlRPYjhDSVFEYmc2SDc1K2thZTk0NwpqaDh5elBSWmlsTmdaZkl3VnFHc0lBUlltMDFGa3c9PQotLS0tLUVORCBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0K","usages":["digital signature","key encipherment","server auth"]}}
CreationTimestamp: Thu, 26 Sep 2019 09:33:42 +0200
Requesting User: kubernetes-admin
Status: Pending
Subject:
Common Name: my-pod.my-namespace.pod.cluster.local
Serial Number:
Subject Alternative Names:
DNS Names: my-svc.my-namespace.svc.cluster.local
my-pod.my-namespace.pod.cluster.local
IP Addresses: 192.0.2.24
10.0.34.2
Events: <none>
Certificate:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
78:45:8b:37:f1:0b:55:66:40:38:b7:0f:07:d2:ec:31:1e:fc:ce:e1
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = kubernetes
Validity
Not Before: Sep 26 07:29:00 2019 GMT
Not After : Sep 25 07:29:00 2020 GMT
Subject: CN = my-pod.my-namespace.pod.cluster.local
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:0d:25:aa:21:15:63:9d:8a:7a:e2:7b:4b:64:c2:
00:ef:a3:fc:fa:91:be:25:0e:5a:e2:d5:0f:59:47:
3a:bc:e8:38:ff:7c:5f:2f:be:c6:13:af:ec:1e:c2:
83:d9:8b:57:67:01:ed:5c:78:46:03:b2:fe:09:9d:
5d:dc:13:8a:56
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
C6:48:1A:B5:B7:6B:E7:77:58:A3:FE:37:56:E2:DF:C3:FB:A1:FE:A6
Signature Algorithm: sha256WithRSAEncryption
50:bc:bf:0e:93:95:9f:2c:b9:5d:8f:03:d2:6d:bc:eb:27:c0:
8e:6c:08:05:8c:68:d7:68:0a:82:84:ef:95:70:5a:a1:e7:cd:
30:4f:95:dd:3d:d7:e1:8b:76:f3:5a:a6:5e:2c:c6:1f:7a:fe:
b0:9c:2b:9c:fa:b5:53:fd:0c:06:a0:18:73:18:34:8b:aa:0b:
58:2a:c0:8c:9b:14:a4:08:fb:9d:01:de:9e:1c:6e:0b:f2:3c:
4e:93:7a:04:02:2b:27:d4:a1:02:bd:11:7a:12:be:5f:aa:89:
e0:52:a3:ea:d8:d2:da:63:d7:1f:67:1d:1a:05:4d:31:9d:ef:
59:da:3c:0b:2d:a2:f5:74:dd:46:19:ab:ea:55:37:69:0d:c2:
ac:f8:aa:5f:e8:07:01:ab:f4:fc:83:9e:73:a2:95:92:68:12:
10:49:a7:f3:16:83:75:c0:ae:0d:77:e0:02:96:b3:e4:e0:61:
1e:f2:9f:70:9e:bc:23:de:94:3d:88:3a:d4:8c:bf:54:77:52:
9a:30:1a:1f:e6:dc:53:b3:31:a7:12:a4:14:74:93:3e:72:c1:
93:6d:29:83:d0:3d:f4:5f:31:64:4e:93:63:17:68:5d:1c:45:
3c:e9:18:4c:1d:bc:7f:a4:d0:82:87:57:cb:ed:f7:74:e0:04:
24:62:dc:4e
-----BEGIN CERTIFICATE-----
MIICXDCCAUSgAwIBAgIUeEWLN/ELVWZAOLcPB9LsMR78zuEwDQYJKoZIhvcNAQEL
BQAwFTETMBEGA1UEAxMKa3ViZXJuZXRlczAeFw0xOTA5MjYwNzI5MDBaFw0yMDA5
MjUwNzI5MDBaMDAxLjAsBgNVBAMTJW15LXBvZC5teS1uYW1lc3BhY2UucG9kLmNs
dXN0ZXIubG9jYWwwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQNJaohFWOdinri
e0tkwgDvo/z6kb4lDlri1Q9ZRzq86Dj/fF8vvsYTr+wewoPZi1dnAe1ceEYDsv4J
nV3cE4pWo1QwUjAOBgNVHQ8BAf8EBAMCBaAwEwYDVR0lBAwwCgYIKwYBBQUHAwEw
DAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQUxkgatbdr53dYo/43VuLfw/uh/qYwDQYJ
KoZIhvcNAQELBQADggEBAFC8vw6TlZ8suV2PA9JtvOsnwI5sCAWMaNdoCoKE75Vw
WqHnzTBPld091+GLdvNapl4sxh96/rCcK5z6tVP9DAagGHMYNIuqC1gqwIybFKQI
+50B3p4cbgvyPE6TegQCKyfUoQK9EXoSvl+qieBSo+rY0tpj1x9nHRoFTTGd71na
PAstovV03UYZq+pVN2kNwqz4ql/oBwGr9PyDnnOilZJoEhBJp/MWg3XArg134AKW
s+TgYR7yn3CevCPelD2IOtSMv1R3UpowGh/m3FOzMacSpBR0kz5ywZNtKYPQPfRf
MWROk2MXaF0cRTzpGEwdvH+k0IKHV8vt93TgBCRi3E4=
-----END CERTIFICATE-----
What you expected to happen:
I'd expect the generated certificate to include the requested alternative names.
How to reproduce it (as minimally and precisely as possible):
Follow the steps described at https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/
Anything else we need to know?:
Environment:
For what its worth, I have raised this issue directly to AWS Technical Support as well.
is there any idea when this will be fixed ?
Any updates on this?
This was originally reported in https://github.com/kubernetes/kubernetes/issues/77092 (from April 19) which was supposedly caused by the same as #244.
I have had this issue previously on eks 1.14, and is still an issue after upgrading to 1.15
i raised with aws support they told me to keep watching this ticket for updates
We are working on this as part of 1.16 support in EKS
Same issue here.
This now supported on EKS for Kubernetes 1.16 and above clusters.
https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#kubernetes-1.16
Great, thanks @mikestef9 for following up.
I can confirm that EKS 1.16 fixed this issue.
Most helpful comment
This now supported on EKS for Kubernetes 1.16 and above clusters.
https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#kubernetes-1.16