Custom value for CN

[mikn]

Right now, CN is hardcoded to be the ip-FQDN of the pod, but for some PKI use cases it makes more sense for this to have other values.
For Searchguard you need to match the node certificate principal with a regex, so the CN needs to be predictable and only cover the nodes themselves. We have solved this by having a flag that sets the headless service DNS name to be set as CN, but it could be more flexible to just allow user input for CN value.

[johngmyers]

I'll have to admit to not understanding headless very well: where the hostname/subdomain eventually come from, how they get into the pod spec, and all that.

The TLS server approval flow I designed parses the ip-FQDN in the subject to find the pod in order to get the information needed to validate the request. To put something else in the CN would require creating an alternate approval flow.

I'll soon be making changes so that some information that currently comes in through flags will instead be grabbed from the API service. You might want to wait for that to land before working on this.

[mikn]

The way headless works is that instead of issuing a service endpoint, a headless service just issues DNS names that can be looked up through an SRV record at {{ service_name }}.{{ namespace }}.svc.cluster.local and the FQDN will then be: {{ pod_hostname }}.{{ service_name }}.{{ namespace }}.svc.cluster.local. So, you can create a headless service by creating a service of type ClusterIP, but without an IP, then kube-dns will create the DNS records, but kube-proxy has no endpoint to point towards. (this is documented in the official documentation)
But, you can also get headless IPs by just giving a value to the subdomain property of the pod spec of a deployment. {{ service_name }}.{{ namespace }}.svc.cluster.local The original intent here was so you can create pods with a FQDN by specifying both hostname and subdomain on your pod, but this gives the same hostname to all pods sharing the same spec.

Can the approval workflow do a DNS lookup of the CN to get the IP instead of parsing the ip-FQDN? That would solve the problem for the use case I'm proposing, at least. :)