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.phil...@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 <j...@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+unsubscr...@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+unsubscr...@googlegroups.com. > To post to this group, send email to kubernetes-sig-a...@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 > <https://groups.google.com/d/msgid/kubernetes-sig-auth/CAD2oYtNsX3tWES61cE-DCHHpB3wsW5f5-hOf%3D%2BehQjRti4C%3DrA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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+unsubscr...@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.
