kubo-deployment
kubo-deployment copied to clipboard
Certificates should be configured with their usages explicitly set
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug
What happened: Certificate Authorities, client certs, and server certificates generated as part of the default manifest are not (all) configured with usages.
With kubo_ca
, we do not set the key_usage
, which results in a CA that doesn't have a usage set for keyCertSign
or cRLSign
:
- name: kubo_ca
type: certificate
options:
is_ca: true
common_name: ca
...
X509v3 extensions:
X509v3 Subject Key Identifier:
DE:CB:42:53:28:57:05:BF:66:05:E6:30:C3:39:52:A1:60:F2:5A:1A
X509v3 Authority Key Identifier:
keyid:DE:CB:42:53:28:57:05:BF:66:05:E6:30:C3:39:52:A1:60:F2:5A:1A
DirName:/CN=ca
serial:65:E3:A2:53:FF:A6:40:C7:0D:ED:82:AB:B7:86:49:65:92:48:42:15
X509v3 Basic Constraints: critical
CA:TRUE
...
While the RFC doesn't explicitly disallow this, it makes little sense to have a CA that doesn't have at least keyCertSign
.
For server certs, we have tls-kubelet
, where we do not set extended_key_usage
to make it clear that this cert is intended as the server cert for kubelet
's API server (e.g. serverAuth
):
- name: tls-kubelet
type: certificate
options:
ca: kubo_ca
organization: "system:nodes"
common_name: kubelet.cfcr.internal
alternative_names: []
The same goes for Docker, Heapster, Dashboard, and so on.
What you expected to happen:
Certs should have both their key_usage
and extended_key_usage
configured and consistent with one another. It's worth consulting both RFC 5280 and the Credhub API.
How to reproduce it (as minimally and precisely as possible):
Deploy CFCR using manifests/cfcr.yml
, check the creds either by pulling them from Credhub, looking at them on the VM, or by using something like openssl s_client
against the API servers.
Anything else we need to know?:
Cert names in the manifest are confusing. tls-kubelet-client
is not a client cert for the kubelet
, but rather a cert that kube-apiserver
presents when communicating with the kubelet
. It's probably worth revisiting the variable names, but the fact that they're also missing their usages only makes it more confusing.
We have created an issue in Pivotal Tracker to manage this:
https://www.pivotaltracker.com/story/show/158703657
The labels on this github issue will be updated when the story is started.
We believe to be impacted by this when going through this tutorial: https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/
Is there a way to work around this in order to complete the tutorial linked above? After approving the request we are not seeing the certificate entering the status of issued.