 Why OpenID Connect is more secure than certificates? My name is Bart Orstein. I'm the CTO of Trimble Security. All right, why certificates? There's strongest credential out there when done correctly. Example, US federal government uses them for their strongest transactions. A lot of industries use them built into smart cards outside of the US federal government. When done correctly, it is a great credential. Done correctly is the important part. We're going to get into that in the next set of slides. It's built directly into Kubernetes. Chances are the first time you used authentication with Kubernetes was with a certificate. You deployed kube-dm, got your admin.conf file, and you were off to the races. So let's talk about what makes a certificate secure. Where does that security come from? You've got three actors here. You've got a key store, a hardware security module, and just about everything these days has a hardware security module. When you're talking about a mobile phone or a server, it could be on a smart card or a YubiKey. And so that's where you're going to keep your key and your certificate. You've got certificate authority. That's where the trust comes from. And you've got web server. Web server trust is certificate authority. The certificate authority trusts you. So on your device, you generate your key pair and you generate a certificate signing request. The certificate signing request is then sent to the certificate authority, not your private key, just your certificate signing request. That contains a public key, as well as some additional metadata information for your CA. CA says, yep, we're going to sign it, signs it with its private key, sends back that certificate. You then install that directly into your key store or hardware security module. You're going to go interact with an application like the API server. You're going to establish connection exchange certificates. At this point, the web server is going to tell you, hey, here are all the issuers that I'm going to trust. Give me a cert from one of these issuers. You present the cert. The web server is going to check a couple of things, including whether or not it's on a certificate revocation list. Identity certificates can be very long live. For instance, those PIV cards, the certificates used by the US federal government often have lives of five years, because they want to keep replacing those cards. If somebody's contract ends, they retire, they leave their agency, their company, whatnot. For whatever reason, that certificate is no longer valid. Guess what? By dates, it's still valid. If you want to make sure that nobody uses it anymore, you need to add it to something called a certificate revocation list. Say this certificate has been revoked. That's how the web server knows, hey, even though the cert is still technically valid from a cryptographic standpoint, it should no longer be trusted. That all checks out. All the trust has validated. Your handshake is established. You do secure stuff. At no point did your private key leave the HSM, and that's where the security of this comes in. The private key, the thing that makes this so secure, never left your HSM, which means in order to get access to it, an attacker would need to have physical access to the HSM. So why wouldn't you use certificates? Well, for one, there is no HSM supporting Kube control right now. PKCS 11, which is a protocol that's used to talk to hardware security modules, is not right now supported by Kube control. That is changing. There is an open KEP, and somebody is being paid to build it, so I'm pretty confident that I'll make it in there in the not too distant future. Now, even if you have that hardware security support, there is no CRL support in the API server. So even if you have access to that hardware certificate, that's really, really strong certificate that you're using to identify users, you can't make sure that that certificate should still be trusted. There is an open issue for it. It hasn't really made a lot of progress. It also was called out as part of the Kubernetes security audit from a couple of years ago. This all assumes that you're deploying your certificates correctly, and quite frankly, that's probably not the case. I don't need to call anybody's baby ugly, but if you're downloading your key pair, if somebody's giving you a conf file, you're not doing it right, and so you're losing a lot of the security benefit there. Group management is really, really hard. You can do groups in a certificate. You can do it as an OU in the subject of the cert, but there are two problems with it. One, you can't revoke the cert, so if your groups change, the cert can't be revoked. Two, you don't want to say, okay, we're going to do it all with RBAC. If you have five or 10 developers doing with RBAC, probably not that big of a deal listing each one in a role binding. You have 50, 100, 1,000 developers in a large enterprise. It's going to be a messy, really, really fast. You want to be able to do groups, and it won't work with the managed cluster. If you're using EKS, GKE, whatever, certificates aren't even an option, not right out of the box, and they won't work the reverse proxy. If you want your API server to validate a certificate directly, guess what? None of that network infrastructure that you have for TLS offloading is going to work. You need to have that direct connection. Now, there is kind of an exception to that. We'll get to that at the end. What makes OpenID connect so great? It's a ratified standard, well, a set of standards. There's like 30 or 40 of them, I think, that make it up. It supports multiple MFA options because it's reliant upon a web browser when done correctly. If you are putting your username and password into a CLI, you're not doing it correctly. That web browser opens up infinite numbers of MFA options where you're talking about something like Duo or Octa. I'm a big fan of U2F, which is the FIDO standard using hardware keys. Lots of possibilities there. It'll work with both on-prem and managed clouds. You can use impersonation with OpenID connect, and it'll work with any cloud. You can have the authenticate the same way to your on-prem stuff as your off-prem stuff. Short live token. You don't have these five-year certificates. You have these one-minute tokens. We'll talk about how that works. The final groups are easy because those tokens are short-lived. It's just a bit of JSON that's digitally signed. You can shove all your groups right in there. All right, so how does OpenID connect work? First thing you do is you authenticate to your identity provider. This part is completely non-standard. This is dependent entirely on your client and your identity provider. OpenUnison has a couple of really nifty ways to automate this without having to deploy anything additional, but there are apps out there to work with both key token decks if you want to go that route. Identity provider is going to give you two tokens, an ID token and a refresh token. The ID token gets you into the party. The refresh token gets you a new ticket when the time comes. If the ID token is still good, when you make a request to the API server, you're just going to put that ID token right into the request. This is what's called a bearer token. This is a security issue. Because you don't need anything else with it, if somebody compromises that token, they can use it against your API server, which is why it's so important to have a short-lived token. Once you're authenticated, you can do your secure stuff. Finally, has the ID token expired? It's been a minute. You need a new token. Now you authenticate, but with the refresh token. The cell happens with kube control behind the scenes. That refresh token is one time use. Once it's used, it's burned. You can't use it again. You get a new refresh token, a new ID token, rinse and repeat until you're done doing your work for the day. OIDC is perfect, right? Not really. Like I said, bearer token, easily abused. There's always a string history of leakage vulnerabilities. One just came out with VMware, I think. It's really important to have those short-lived tokens. It can be difficult to implement a lot of different steps, different projects in there. Whereas with certificates, it's a direct connection. That can make it harder to implement and harder to debug. But what about using vault copy certs and all sorts of other schemes that I've seen? Ultimately, you're re-implementing OpenIDConnect's refresh process, but without the thousands of hours of peer review that OpenID has gotten. Chances are, unless you work at one of the larger cloud vendors, you're not going to have enough eyes on whatever you develop to equal the amount of time that's been put into OpenIDConnect. I really want certs. Great. Use certs with OpenIDConnect. Have your identity provider authenticate with the certificate. Check your CRL. You're off to the races. That doesn't work for you. Use a reverse proxy with impersonation. Your reverse proxy checks the cert, checks the CRL. Uses impersonation with the API server. Works in both cloud and on-prem solutions. Hey, thanks very much for taking the time to learn about certificates. You can find me on the Twitter at mlbiam. And if you're looking for an OpenIDConnect identity provider for your Kubernetes deployment, take a look at OpenUnison. It's our open-source project. OpenIDConnect, SAML, LDAP, the works. Multi-factor all there. Thanks and enjoy KubeCon.