[BUG] Amazon EKS generated Certificates are missing the SANS configuration

[diranged]

Describe the bug
When trying to setup Kyverno on an Amazon EKS-managed Kubernetes cluster the SSL Certificate returned by Kubernetes is insufficient to allow the kube-apiserver to hit the kyverno-svc:443 endpoint. The issue is that the Amazon-managed kube-apiserver generates an SSL certificate without the Subject Alternative Names configuration that is requested, which means the certificate cannot be validated against the hostname that the service operates under. Another open bug in the Amazon EKS AMI repo (awslabs/amazon-eks-ami#341) documents this clearly.

To Reproduce
Steps to reproduce the behavior:

1. Launch an EKS cluster properly (out of scope of this bug)
2. kubectl apply -f .../install.yaml
3. Describe the certificate request:

$ k describe csr kyverno-svc.kyverno.cert-request 
Name:               kyverno-svc.kyverno.cert-request
Labels:             <none>
Annotations:        <none>
CreationTimestamp:  Mon, 09 Dec 2019 12:10:43 -0800
Requesting User:    system:serviceaccount:kyverno:kyverno-service-account
Status:             Approved,Issued
Subject:
  Common Name:    kyverno-svc
  Serial Number:  
Subject Alternative Names:
         DNS Names:     kyverno-svc
                        kyverno-svc.kyverno
                        kyverno-svc.kyverno.svc
         IP Addresses:  172.20.0.1
Events:  <none>

4. Read the certificate content itself and see the missing SANS:

$ k get csr kyverno-svc.kyverno.cert-request -o json | jq -r .status.certificate | base64 -D  | openssl x509 -noout -text 
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            ....
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=kubernetes
        Validity
            Not Before: Dec  9 20:06:00 2019 GMT
            Not After : Dec  8 20:06:00 2020 GMT
        Subject: CN=kyverno-svc
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b6:7f:b7:93:9a:20:26:43:8f:aa:05:17:7f:a9:
                    ....
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier: 
                ....
    Signature Algorithm: sha256WithRSAEncryption
         02:bb:79:c3:1b:dd:f5:d8:ce:87:fe:53:af:96:b8:d7:4a:20:
         ...
         15:e3:1a:a3

Expected behavior
Ideally the CN for the certificate would be the fully qualified name, and the SANS would contain the "short name" for convenience but not as a requirement.

[shivdudhani]

Test if using CN as the FQDN works on all platform, if yes can be the default behavior.

[shivdudhani]

Moving this out of GA, as needs further testing before defining the default behavior.

[diranged]

Rather than making it the default - can you merge it in as a configurable option?

[shivdudhani]

@JimBugwadia
This can be made configurable by providing a commad-line argument to use FQDN as Common Name in CSR due to the current limitation of certs returned by EKS.
suggested name for argument: FQDNCN

[shivdudhani]

Introduced a command-line argument fqdncn to generate CSR with FQDN as the CommonName.
PR https://github.com/nirmata/kyverno/pull/599