A proposal based on the discussion of issue #18112, to implement a process by which kubelets can obtain TLS certificates in a streamlined manner.

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please let us know the company's name.

Can one of the admins verify that this is reasonable to test? (reply "ok to test", or if you trust the user, reply "add to whitelist")

If this message is too spammy, please complain to ixdy.

Can one of the admins verify that this is reasonable to test? (reply "ok to test", or if you trust the user, reply "add to whitelist")

If this message is too spammy, please complain to ixdy.

CLAs look good, thanks!

@liggitt and @deads2k, parallels lots of discussions on cluster CSR

What defense does this API need against abuse?

The abuse concerns I've considered are 1) DoS by making excessive requests and 2) unauthorized certificate issuance. We mitigate the first by restricting the endpoint itself with token auth (on the assumption that nodes you have provisioned are unlikely to DoS you) and the second by requiring manual intervention to approve CSRs.

In the future, we'd like to implement more robust approval policies (e.g. involving ACME handshakes or TPM attestation) on top of this mechanism.

Can one of the admins verify that this is reasonable to test? (reply "ok to test", or if you trust the user, reply "add to whitelist")

If this message is too spammy, please complain to ixdy.

Can one of the admins verify that this is reasonable to test? (reply "ok to test", or if you trust the user, reply "add to whitelist")

If this message is too spammy, please complain to ixdy.

[mikedanese]

@erictune what would be a good API group to add this too? Will we have an authentication api group eventually to house user and group objects? That seems like a reasonable place to put these types.

[liggitt]

This is more pki/ca-related than auth

[gtank]

I have it under extensions for now. Will move it to a more appropriate location when we can figure out where that is.

[deads2k]

I have it under extensions for now. Will move it to a more appropriate location when we can figure out where that is.

No more under extensions please. We can argue over the exact name in the pull or here, but I don't want any more "temporary" resources under extensions.

@erictune I assigned to you to do an initial review since it's auth related.

cc @roberthbailey @bgrant0607 @davidopp @jbeda

This is a little left field, but have we considered perhaps using/adapting the ACME protocol used by Let's Encrypt?

https://tools.ietf.org/html/draft-ietf-acme-acme-01

It is very similar to the flow in the doc but with some important differences:

• There idea of a user that has control over an identity is different from the requests for certificates. This opens the door for certificate rotation and requests for different types of (perhaps down-scoped) certs.
• There are an extensible set of "challenges" that can be used to verify the client. This opens the door for more sophisticated identity proof systems in the future.
• This opens the door for the CA to be run separately from the master with few/no changes to the kubelet/client. This may be an important security consideration.

A lot of the block and tackle for LetsEncrypt is written in go already -- https://.com/letsencrypt/boulder. While we probably won't want to use this stuff verbatim, it may be possible to break out parts of the implementation and share (etcd raft-like).

My motivation: I'd love to see an extensible identity system that is "dialtone" in clusters not just for the cluster system itself but for applications. Basically, we'll have the problem of "microservice A calls microservice B. How does B know it is actually A that is calling". This is obviously out of scope for k8s but it would be great to be compatible and share code.

One big disadvantage here: This doesn't reuse the API patterns used through the rest of Kubernetes. I think this is probably a viable trade off as we wouldn't be rolling our own security related APIs.

[lavalamp]

I'd recommend adding a /approve subresource for this-- we don't ordinarily do a bunch of computation when you write to an object.

A /reject subresource isn't necessary for this, since in that case the apiserver is just filling in fields, as in an ordinary update.

[gtank]

sgtm. I'm not terribly familiar with the API conventions yet and this still struck me as a rough edge.

I think it's in scope for the ecosystem to build up something capable of allowing that. Agree it may not be Kube core, but it's pretty fundamental.

@smarterclayton -- Wrt app->app authn, I'm thinking that something as part of the CNCF might make sense. I'm going to write a design doc over the next couple of weeks and share it around. Stay tuned.

@mikedanese How about doing the conditions like this?

[mikedanese]

I think this filed should be moved to the body of status.

The api needs refining but this is going to be an alpha api for 1.3 so there will be significant api reviews later. LGTM'ing to unblock progress on an implementation.

GCE e2e build/test passed for commit 5a65bb0.

• Build Log
• Test Artifacts
• Internal Jenkins Results

Automatic merge from submit-queue

[smarterclayton]

I didn't see a discussion (or missed it in a previous version) but can I watch the list and steal someone else's certificate?

[liggitt]

Neither the csr nor the cert contains the private key of the node. A cert just holds the public key half, and isn't a secret (it's presented by the node in every TLS handshake)

[smarterclayton]

Oh, right.

On Tue, May 3, 2016 at 11:19 PM, Jordan Liggitt [email protected]
wrote:

In docs/proposals/kubelet-tls-bootstrap.md
#20439 (comment)
:

+1. Approved if the controller should issue the cert
+2. Denied if the controller should not issue the cert
+
+The suggested command for listing is kubectl get csrs. The approve/deny
+interactions can be accomplished with normal updates, but would be more
+conveniently accessed by direct subresource updates. We leave this for future
+updates to kubectl.
+
+## Security Considerations
+
+### Endpoint Access Control
+
+The ability to post CSRs to the signing endpoint should be controlled. As a
+simple solution we propose that each node be provisioned with an auth token
+(possibly static across the cluster) that is scoped via ABAC to only allow
+access to the CSR endpoint.

Neither the csr nor the cert contains the private key of the node. A cert
just holds the public key half, and isn't a secret (it's presented by the
node in every TLS handshake)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on
https://.com/kubernetes/kubernetes/pull/20439/files/5a65bb0044d9ac3fc3e7585d09cb6bb33e9c3b2c#r61986759

@gtank Are there any plans to extend the CSR api proposed here, to support service->service mutual tls auth? something like
https://.com/allingeek/pollendina#architecture

We've had a fair number of discussions about how client certs / serving certs might be generated. I personally prefer approaches where the infrastructure can sign for services to have certs injected, but that does not directly solve the client problem. I do like the ideas endorsed in your link, of being able to request signing.