enable support for non-expiring certificates

[sym3tri]

So users don't get locked out of their clusters.

Make expiry duration an explicit choice during provisioning, and/or default to not expiring.

[iameli]

Related to #561, which is the ticket to allow for updating TLS assets in CloudFormation on AWS.

[philips]

Lets use 3153600000 seconds. This is about 68 years and the max you can do. https://groups.google.com/forum/#!topic/mailing.openssl.users/3kK_f0ywCZQ

[philips]

Once you get back can you take this over @colhom ?

[mike-saparov]

Can we not use 68 years, users will never pass any security certification with such settings... We are encouraging a bad practice IMHO. Can we instead consider very aggressive notification about certificate expiration?

[aaronlevy]

How about we just let people choose as an option?

[sym3tri]

How about we just let people choose as an option?

My original suggestion was to force a choice.
No defaults == no surprises.
Choice == choose-your-own-security.

[peebs]

It sounds like our original reason for expiring the certs was to force people to come up with a better solution if they use this in production. Its not that unlimited certs are particularly less secure then our 90 day certs because its YOLO either way if people can't update or revoke certs. Its just that 90 days forces people to take control over their TLS infra or be broken.

It seems like we should do something in the interim between now and having auto-tls boostraping and auto-rotation (sounds like the v1.5 timeframe for it all to work). It is just such an awful user experience otherwise to have the cluster hard-fail at 90 days.

Talking with @aaronlevy and @gtank It seems like a reasonable solution for now is to:

• leave the default expiration but add a warning on when they start the cluster
• add an --insecure-yolo-unlimited-tls option for those that would do this anyway.

@sym3tri We could also force the choice and not provide a default expiration, but if most users are going to choose 10 years anyway, I'd rather them be forced to pick the yolo option. I don't feel very strongly about this last point though. Any thoughts?

[sym3tri]

sounds like the v1.5 timeframe for it all to work

I thought everything was merged & ready to go in 1.4?

but if most users are going to choose 10 years anyway, I'd rather them be forced to pick the yolo option

If they are choosing 10 years, they are essentially choosing the yolo option, no? I'd think that adding an addition flag would result in even more confusion. If we do force the flag we could document the best-practices with the flag, and also show a warning if an expiry greater than reasonable is chosen.

[peebs]

I thought everything was merged & ready to go in 1.4?

I believe we only have auto cert generation for client certs in v1.4. There is some outstanding work to be done before we have full-automation and rotation as an option AFAIK.

If they are choosing 10 years, they are essentially choosing the yolo option, no? I'd think that adding an addition flag would result in even more confusion. If we do force the flag we could document the best-practices with the flag, and also show a warning if an expiry greater than reasonable is chosen.

I think I am somewhat against the forcing users to choose because it is a bit of a false choice:

• All expirations dates are insecure/problematic without the ability to revoke and easily rotate.
• Existing behavior is thus also insecure/problematic but forces you to figure out a better solution 90 days in or else.

So, if we force a flag to configure expiration, its hard to recommend best-practices. That leaves us with forcing a user to fill in a value for --always-insecure-tls-expiration=??.

So since we have a solution coming soon that will fix the UX and security problem all at once (wow) I'd rather sort of cheat here and preserve existing behavior but mitigate the UX problem with warnings. Then, we add an insecure-escape-hatch flag that allows unlimited length anyway, but its an optional and conscious choice. Ideally for users who plan to outright delete their CA and certs at some point.

[philips]

To make everyone happy I think we should set it to something "reasonable" like say 6 years and then make it configurable for people who have more stringent security needs. Does this make everyone happy? cc @mike-saparov @sym3tri ?

[sym3tri]

For various reasons we've actually decided to do the TLS generation ourselves in our installers so I have less of a vested interest in this now. I'm fine with whatever you guys decide.

[whereisaaron]

It is great that kube-aws will be able to generate sustainable certs (#561). In the interim I had rolled a rough script to generate certs compatible with kube-aws that won't lock us out in a couple months :-)

https://github.com/whereisaaron/coreos-kubernetes-generate-certs

Are you using something fancier @sym3tri ?

Because there is currently no practical mechanism to roll certs across a cluster, we generate them per cluster and treat the cluster as a regularly disposable/replaceable part of deployment.

[sym3tri]

@whereisaaron we are just generating our own CA & Certs instead of having kube-aws do it for us.

[peebs]

fixed in: #645