Update TLS cert for most of the aliases about k8s.io HOT 27 CLOSED

There's already some prior work on supporting Lets Encrypt on Kubernetes (kubernetes/kubernetes#19899, https://github.com/munnerz/kube-acme, https://github.com/jetstack/kube-lego, https://github.com/kelseyhightower/kube-cert-manager, https://github.com/iameli/kubernetes-letsencrypt, http://blog.ployst.com/development/2015/12/22/letsencrypt-on-kubernetes.html) though as best I can tell none of it is really production-ready.

Buying wildcard certs for *.k8s.io and *.kubernetes.io for at least a year seems like the best option.

from k8s.io.

@ixdy

from k8s.io.

There are a few others missing, too:

• ci-test.k8s.io
• gcsweb.k8s.io
• go.k8s.io
• pr-test.k8s.io

and also all of the *.kubernetes.io variants of all of these. And we'll undoubtedly have more as we add additional vanity subdomains.

I think we want to move to LetsEncrypt certs instead of the Google-issued one we have right now. This would let us add additional vanity subdomains fairly easily, but someone needs to setup the automation around this. (LE does not do wildcard certs, either.)

We have about 2 months to get this done.

from k8s.io.

https://github.com/AnalogJ/lexicon with https://github.com/AnalogJ/lexicon/blob/master/examples/letsencrypt.default.sh should do the trick.

How do you maintain DNS records? Is there any .yaml with records?

from k8s.io.

I have seen about such client libs. I don't have time to try them all. I
need a recommendation of one that is trustworthy and easy and can pull a
cert with an arbitrary number of SANs.

On Sun, Oct 9, 2016 at 1:44 PM, anatoly techtonik [email protected]
wrote:

https://github.com/AnalogJ/lexicon with https://github.com/AnalogJ/
lexicon/blob/master/examples/letsencrypt.default.sh should do the trick.

How do you maintain DNS records? Is there any .yaml with mapping?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#18 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVGYDdJVgnLiCfO4mq6pUuXcGqx08ks5qyVIegaJpZM4KOMiq
.

from k8s.io.

Let's encrypt allows to --expand existing certificate with more names - http://stackoverflow.com/questions/35777157/how-to-add-change-certificates-issued-by-letsencrypt, but k8s.io domains use Google Internet authority, which is not accessible to public and hence doesn't have public API or client libs. So a decision to switch to let's encrypt should be taken first.

from k8s.io.

Yeah, if we're going to switch we have to switch it all.

On Mon, Oct 10, 2016 at 12:44 AM, anatoly techtonik <
[email protected]> wrote:

Let's encrypt allows to --expand existing certificate with more names -
http://stackoverflow.com/questions/35777157/how-to-add-
change-certificates-issued-by-letsencrypt, but k8s.io domains use Google
Internet authority, which is not accessible to public and hence doesn't
have public API or client libs. So a decision to switch to let's encrypt
should be taken first.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#18 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVOCP8zycFnrvT984EW533D4i41upks5qyezrgaJpZM4KOMiq
.

from k8s.io.

anyone else have opinions or want to help with this? I'm probably going to start trying to figure out stuff myself, since the clock is ticking on our certs expiring.

from k8s.io.

(I apparently can't assign issues to myself in this repo. :( )

from k8s.io.

codereview.kubernetes.io is expiring soon too, so we'll need to figure out some plan for it as well.

from k8s.io.

per another thread with @dankohn and @caniszczyk ... I'll buy these personally from let's encrypt and expense to LF/CNCF. Who should I work with for the request?

from k8s.io.

@sarahnovotny certs from Let's Encrypt are free. The issue is that the certs are only good for 90 days, since they want to force you to use automation. We could get certs to buy us another 90 days, but we do need to figure out the automation.

from k8s.io.

aah. i suggest then that I buy certs and solve this problem with money for a few years instead of (already straining) developer time.

.s.

from k8s.io.

@sarahnovotny If you could buy 3-year wildcard domains for *.k8s.io and *.kubernetes.io (and expense them to me and @bprestonlf), I'm optimistic we'll get around to implementing Let's Encrypt certificate renewals before these new ones expire. Thanks everyone for the help on this.

from k8s.io.

@ixdy, since nobody volunteered, I am willing to help with automation, because I am going to build some universal domain management automation anyway for local hackerspace in Minsk (we have many domains from hackatons and other events that couldn't just die).

@sarahnovotny, if you can secure some resources to backup my work, that would help me to focus and make it till deadline, which is 12/31/2016, according to expiry date on reviewable.k8s.io cert (not codereview.kubernetes.io, which doesn't exist in managed inventory list).

Let's encrypt requires either access to DNS to validate domain ownership, or certbot running on host machine and responding on certain endpoint. certbot or similar automation is needed to retrieve new certificate and install it on web server. The roadmap:

• get list of managed domains
• identify nodes with web servers that respond to queries on managed domains
• provide identity confirmation for web servers
  • research DNS way
    • check if Google DNS has public API
    • switch to DNS provider with public API
    • move domains to alternative DNS provider
  • certbot way
    • identify how to insert certbot for every node's web server
• fetch certificates and install on node's web server
  • research certbot way
    • multiple nodes with multiple certbots serving the same domain
  • research alternative way
    • certificates stored/fetched from network mount
    • own script for getting certificates

More automation that could be added after deadline above:

• API to query deadlines for expired certificates (#30)
• API to query expiring domains
• automated domain (and other service) payment
  • crowdsourced domain payment
  • resource (finance) health monitoring for domain management
• change history / log
  ...

from k8s.io.

@techtonik the k8s.io cert (which is used on a bunch of the vanity subdomains) expires Dec 7 2016.

from k8s.io.

yes. I'm happy to do that and expense it to the CNCF per an earlier convo. I need the CSR info who can get me that?

from k8s.io.

probably @thockin. we can discuss next week after Kubecon?

from k8s.io.

@sarahnovotny @thockin @bgrant0607 kubernetes.io is showing a certificate error in Chrome.

from k8s.io.

http://kubernetes.io works OK but https://kubernetes.io is showing an error.

from k8s.io.

@dankohn yes, it has always done that. kubernetes.io is currently being served by GitHub Pages, so it doesn't have a valid cert (it's trying to use github's instead of ours). see e.g. isaacs/github#156.

Fixing that is a separate issue.

from k8s.io.

Got it, thanks.

from k8s.io.

I played around with using https://github.com/ixdy/kubernetes-certbot, forked from https://github.com/dwnld/kubernetes-certbot, itself forked from https://github.com/choffmeister/kubernetes-certbot, with a proof of concept for get.k8s.io in ixdy@c89d75d.

It basically worked, but it'd need some work to fully productionize:

• the domain list in configmap-certbot.yaml is manually generated
• we'd have to add a location /.well-known/acme-challenge/ block for every subdomain in the nginx, which is dumb.
• we'd need to make nginx automatically restart when the cert is refreshed, as otherwise we might use expired certs
• kubernetes-certbot has probably no production history, so it's unclear whether it'd continue to work

I think we're still planning to get a wildcard cert for *.k8s.io and *.kubernetes.io for at least a year. That way we'll have more than 5 days to figure out if there's an alternate way to do this with LE.

from k8s.io.

The k8s.io redirector has been updated with a new TLS cert from LE using lego. Basic steps I followed:

• Generate list of domains (as arguments):

for d in $(egrep '^(\s|\t)*server_name' configmap-nginx.yaml | sed -r 's/(.*server_n
ame\s*|;)//g' | sort | uniq); do echo -n "--domains=$d "; done; echo

• Reorder domains so k8s.io, kubernetes.io, and kubernet.es were first
• Debug lego for a while, eventually filing go-acme/lego#330, and eventually getting certs.
• Deploy certs manually to the k8s.io cluster.

This process is now down probably to ~10m of manual work. If we put the k8s.io redirector behind an ingress, it'd probably be even easier to automate running LE directly on k8s.

from k8s.io.

from k8s.io.

yep, did that as part of the "deploy certs" step.

from k8s.io.

Going to close this since we have a TLS cert covering all of the current aliases. We still need to figure out how to automate it.

from k8s.io.