Authentication via certificates

[logan064]

trafficstars

Is there a way to authenticate using docker_auth via client certificates instead of username/password?

All of the information uses a username password combo instead of client certificates.

[techknowlogick]

Not possible currently, however I'm interested if you have an example from another provider including how to log in w/ docker (or other compatible OCI client) as all I can find is some vague examples w/ nginx

[logan064]

Currently the docker registry server's config.yml allows you to specify clientcas to give trusted CAs. This allows only clients that have a client certificate in /etc/containers/certs.d/localhost:5000 that is signed by a a trusted CA. You can substitute the localhost:5000 with the endpoint of your registry, obviously. This works great, but does not allow the ACLs to be applied. I am using podman 2.2.1, but I know docker has a similar capability. Is there any way to piggy back off of the client certificates in the certs.d subdirectories?

[rojer]

we could retrieve attributes of the client cert and add them to labels so authz phase could access them

[logan064]

Is authz the authorization phase, i.e. ACL?

Could the CN be treated as account and O as the group? That is similar to what kuberenetes does with their certificates.

[rojer]

yes, authz is the authorization / ACL matching phase, authn (authentication) in this case is the TLS handshake. i don't think we should be statically rewriting CN to account, just stuff attributes into labels and let the user (of docker auth, i.e. the admin) express rules based on them in the ACL entries themselves.

[rojer]

so, e.g. CN value will be put into TLS_CN, O into TLS_O, etc.

[logan064]

That sounds good!

[rojer]

TLS certificate can be accessed via the http.Request.TLS.PeerCertificates field. we only need to examine the first entry of the slice, which is the client certificate itself, the rest (if any) are the intermediate CA certs.