Add client cert authentication #6190
Conversation
|
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA) at https://cla.developers.google.com/. If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check the information on your CLA or see this help article on setting the email on your git commits. Once you've done that, please reply here to let us know. If you signed the CLA as a corporation, please let us know the company's name. |
liggitt
force-pushed
the
client_cert_auth
branch
2 times, most recently
from
43279fc
to
d4b79ca
Compare
|
Assigning to @erictune, I think you'd know who to better assign to if you need to rebalance :) |
liggitt
force-pushed
the
client_cert_auth
branch
2 times, most recently
from
5cd94df
to
9ed88b2
Compare
|
Yoink. I was actually going to add this in a few days so I'll take a look. |
| if block == nil { | ||
| break | ||
| } | ||
| if block.Type != "CERTIFICATE" || len(block.Headers) != 0 { |
There was a problem hiding this comment.
What does it mean if there are no headers? You don't use the headers anywhere below.
Can you add a comment why we skip blocks w/o headers?
There was a problem hiding this comment.
It means that CertPool#AppendCertsFromPEM would not add it :)
http://golang.org/src/crypto/x509/cert_pool.go?s=2159:2223#L75
It means that only PEM "CERTIFICATE" blocks without extra headers get parsed as CA certificates
liggitt
force-pushed
the
client_cert_auth
branch
from
9ed88b2
to
147e6c4
Compare
|
comments addressed |
|
looks like travis blipped |
liggitt
force-pushed
the
client_cert_auth
branch
2 times, most recently
from
e017026
to
23a182c
Compare
|
LGTM. Will give @erictune a chance to weigh in before merging. |
| @@ -139,6 +140,7 @@ func (s *APIServer) AddFlags(fs *pflag.FlagSet) { | |||
| fs.StringVar(&s.CloudProvider, "cloud_provider", s.CloudProvider, "The provider for cloud services. Empty string for no provider.") | |||
| fs.StringVar(&s.CloudConfigFile, "cloud_config", s.CloudConfigFile, "The path to the cloud provider configuration file. Empty string for no configuration file.") | |||
| fs.DurationVar(&s.EventTTL, "event_ttl", s.EventTTL, "Amount of time to retain events. Default 1 hour.") | |||
| fs.StringVar(&s.ClientCAFile, "client_ca_file", s.ClientCAFile, "If set, the file that will be used to secure the secure port of the API server via client cert authentication.") | |||
There was a problem hiding this comment.
Would it be correct to say: "If set, any client presenting a cert signed by the CA in client_ca_file is authenticated with an identity corresponding to the CN of the client cert."
If so, I think that is a clearer flag description.
liggitt
force-pushed
the
client_cert_auth
branch
from
23a182c
to
c797a91
Compare
| // This allows certificates to be validated by authenticators, while still allowing other auth types | ||
| secureServer.TLSConfig.ClientAuth = tls.RequestClientCert | ||
| // Specify allowed CAs for client certificates | ||
| secureServer.TLSConfig.ClientCAs = clientCAs |
There was a problem hiding this comment.
What if I am accessing the apiserver via my browser and I have installed a client cert from a CA which is not in the clientCAs pool? Then I automatically get rejected. That seems wrong.
If we tried to expand the clientCAs pool to include our cluster's CA plus all known trustworthy CAs, then it would mean that anyone with a client cert from any of those CAs could authenticate to our cluster, which is also not good.
So, I think the set of allowed client CAs needs to be broader than the set of automatically-authenticating client CAs.
There was a problem hiding this comment.
If there is a way to set the TLSConfig to allow connections with any cert, and do all the checking in the Authenticator, then I think that is the way to go for now?
There was a problem hiding this comment.
You won't get rejected.
Setting ClientAuth=RequestClientCert means a client cert is requested, but not required or validated at the connection level.
Setting ClientCAs tells clients what CAs are valid to present client certificates for. If your browser doesn't have any client certificates for that CA, it won't send any. Leaving ClientCAs blank means some browsers will try to send any client cert they have.
There was a problem hiding this comment.
If there is a way to set the TLSConfig to allow connections with any cert, and do all the checking in the Authenticator, then I think that is the way to go for now?
That's exactly what this does. See "This allows certificates to be validated by authenticators, while still allowing other auth types" comment :)
Requests without client certs, with invalid client certs, or with valid client certs are all allowed at the transport layer.
Requests without a client cert will skip the client cert Authenticator.
Requests with an "invalid" client cert will fail the client cert Authenticator, but could still get an identity from the token Authenticator.
Requests with a valid client cert will get an identity from the client cert Authenticator.
|
I just have the one area that I think needs a change. |
|
LGTM |
Add client cert authentication
No description provided.