Re: [kubernetes-users] SSL endpoints: certs w/o IP SANs ok?

[Brandon Philips]

Hello John-

Today, etcd will not enforce IP SANs but we just merged a change where it will enforce them IF they exist. Expect this change in a future release of etcd v3.2.[1]

I forget the exact details on why IP SANs are necessary in the certificates. However, IIRC there are some places in Kubernetes where only IPs are valid. Adding SIG Auth.

Brandon 

[1] https://github.com/coreos/etcd/pull/7687

On Mon, Apr 17, 2017 at 10:33 AM John Morris <jo...@zultron.com> wrote:

In a CoreOS cluster migrating from fleet to Kubernetes (initial planning stage), the CA is part of FreeIPA, which refuses to issue certs with IP SANs [1].  However, the CoreOS Kubernetes [2] and other documentation all call for issuing certs with IP SANs.  Is this a strict requirement, or can DNS SANs be sufficient?  (For someone more conversant with k8s, it looks like the answer could be found in issue #22063 [3].)

IIRC, the etcd2 docs also called for IP SANs, but using fqdns in endpoint URLs turned out to be possible.  Hopefully this is just another case where the docs omit less common configurations.  It's been really nice having a single, org-wide CA and letting certmonger keep certs up to date for all services on all nodes.  Thanks-

        John

[1]: https://www.redhat.com/archives/freeipa-users/2016-October/msg00053.html
[2]: https://coreos.com/kubernetes/docs/latest/openssl.html#openssl-config
[3]: https://github.com/kubernetes/kubernetes/issues/22063

--
You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-use...@googlegroups.com.
To post to this group, send email to kubernet...@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

[Jordan Liggitt]

Some clients inside pods talk to the API server via https://$KUBERNETES_SERVICE_HOST:$KUBERNETES_SERVICE_PORT, where $KUBERNETES_SERVICE_HOST is the IP of the service injected into the pod as an envvar, hence the IP SAN.

On Mon, Apr 17, 2017 at 8:32 PM, Brandon Philips <brandon...@coreos.com> wrote:

Hello John-

Today, etcd will not enforce IP SANs but we just merged a change where it will enforce them IF they exist. Expect this change in a future release of etcd v3.2.[1]

I forget the exact details on why IP SANs are necessary in the certificates. However, IIRC there are some places in Kubernetes where only IPs are valid. Adding SIG Auth.

Brandon 

[1] https://github.com/coreos/etcd/pull/7687

On Mon, Apr 17, 2017 at 10:33 AM John Morris <jo...@zultron.com> wrote:

In a CoreOS cluster migrating from fleet to Kubernetes (initial planning stage), the CA is part of FreeIPA, which refuses to issue certs with IP SANs [1].  However, the CoreOS Kubernetes [2] and other documentation all call for issuing certs with IP SANs.  Is this a strict requirement, or can DNS SANs be sufficient?  (For someone more conversant with k8s, it looks like the answer could be found in issue #22063 [3].)

IIRC, the etcd2 docs also called for IP SANs, but using fqdns in endpoint URLs turned out to be possible.  Hopefully this is just another case where the docs omit less common configurations.  It's been really nice having a single, org-wide CA and letting certmonger keep certs up to date for all services on all nodes.  Thanks-

        John

[1]: https://www.redhat.com/archives/freeipa-users/2016-October/msg00053.html
[2]: https://coreos.com/kubernetes/docs/latest/openssl.html#openssl-config
[3]: https://github.com/kubernetes/kubernetes/issues/22063

--
You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.

Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-auth" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-auth+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-sig-auth@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-auth/CAD2oYtNsX3tWES61cE-DCHHpB3wsW5f5-hOf%3D%2BehQjRti4C%3DrA%40mail.gmail.com.