PKI証明書とその要件
Kubernetes requires PKI certificates for authentication over TLS. If you install Kubernetes with kubeadm, the certificates that your cluster requires are automatically generated. You can also generate your own certificates – for example, to keep your private keys more secure by not storing them on the API server. This page explains the certificates that your cluster requires.
あなたのクラスタではどのように証明書が使われているのか
Kubernetes requires PKI for the following operations:
- Client certificates for the kubelet to authenticate to the API server
- Server certificate for the API server endpoint
- Client certificates for administrators of the cluster to authenticate to the API server
- Client certificates for the API server to talk to the kubelets
- Client certificate for the API server to talk to etcd
- Client certificate/kubeconfig for the controller manager to talk to the API server
- Client certificate/kubeconfig for the scheduler to talk to the API server.
- Client and server certificates for the front-proxy
Note:front-proxycertificates are required only if you run kube-proxy to support an extension API server.
etcd also implements mutual TLS to authenticate clients and peers.
証明書の保存場所
If you install Kubernetes with kubeadm, certificates are stored in /etc/kubernetes/pki. All paths in this documentation are relative to that directory.
手動で証明書を設定する
If you don’t want kubeadm to generate the required certificates, you can create them in either of the following ways.
単一ルート認証局
You can create a single root CA, controlled by an administrator. This root CA can then create multiple intermediate CAs, and delegate all further creation to Kubernetes itself.
Required CAs:
| path | Default CN | description |
|---|---|---|
| ca.crt,key | kubernetes-ca | Kubernetes general CA |
| etcd/ca.crt,key | etcd-ca | For all etcd-related functions |
| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | For the front-end proxy |
全ての証明書
If you don’t wish to copy these private keys to your API servers, you can generate all certificates yourself.
Required certificates:
| Default CN | Parent CA | O (in Subject) | kind | hosts (SAN) |
|---|---|---|---|---|
| kube-etcd | etcd-ca | server, client [1][etcdbug] | localhost, 127.0.0.1 |
|
| kube-etcd-peer | etcd-ca | server, client | <hostname>, <Host_IP>, localhost, 127.0.0.1 |
|
| kube-etcd-healthcheck-client | etcd-ca | client | ||
| kube-apiserver-etcd-client | etcd-ca | system:masters | client | |
| kube-apiserver | kubernetes-ca | server | <hostname>, <Host_IP>, <advertise_IP>, [1] |
|
| kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | |
| front-proxy-client | kubernetes-front-proxy-ca | client |
[1]: kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster, kubernetes.default.svc.cluster.local
where kind maps to one or more of the x509 key usage types:
| kind | Key usage |
|---|---|
| server | digital signature, key encipherment, server auth |
| client | digital signature, key encipherment, client auth |
証明書のパス
Certificates should be placed in a recommended path (as used by kubeadm). Paths should be specified using the given argument regardless of location.
| Default CN | recommend key path | recommended cert path | command | key argument | cert argument |
|---|---|---|---|---|---|
| etcd-ca | etcd/ca.crt | kube-apiserver | –etcd-cafile | ||
| etcd-client | apiserver-etcd-client.crt | apiserver-etcd-client.crt | kube-apiserver | –etcd-certfile | –etcd-keyfile |
| kubernetes-ca | ca.crt | kube-apiserver | –client-ca-file | ||
| kube-apiserver | apiserver.crt | apiserver.key | kube-apiserver | –tls-cert-file | –tls-private-key |
| apiserver-kubelet-client | apiserver-kubelet-client.crt | kube-apiserver | –kubelet-client-certificate | ||
| front-proxy-client | front-proxy-client.key | front-proxy-client.crt | kube-apiserver | –proxy-client-cert-file | –proxy-client-key-file |
| etcd-ca | etcd/ca.crt | etcd | –trusted-ca-file, –peer-trusted-ca-file | ||
| kube-etcd | etcd/server.crt | etcd | –cert-file | ||
| kube-etcd-peer | etcd/peer.key | etcd/peer.crt | etcd | –peer-key-file | –peer-cert-file |
| etcd-ca | etcd/ca.crt | etcdctl[2] | –cacert | ||
| kube-etcd-healthcheck-client | etcd/healthcheck-client.key | etcd/healthcheck-client.crt | etcdctl[2] | –key | –cert |
[2]: For a liveness probe, if self-hosted
ユーザアカウント用に証明書を設定する
You must manually configure these administrator account and service accounts:
| filename | credential name | Default CN | O (in Subject) |
|---|---|---|---|
| admin.conf | default-admin | kubernetes-admin | system:masters |
| kubelet.conf | default-auth | system:node:<nodename> |
system:nodes |
| controller-manager.conf | default-controller-manager | system:kube-controller-manager | |
| scheduler.conf | default-manager | system:kube-scheduler |
For each config, generate an x509 cert/key pair with the given CN and O.
Run
kubectlas follows for each config:
KUBECONFIG=<filename> kubectl config set-cluster default-cluster --server=https://<host ip>:6443 --certificate-authority <path-to-kubernetes-ca> --embed-certs
KUBECONFIG=<filename> kubectl config set-credentials <credential-name> --client-key <path-to-key>.pem --client-certificate <path-to-cert>.pem --embed-certs
KUBECONFIG=<filename> kubectl config set-context default-system --cluster default-cluster --user <credential-name>
KUBECONFIG=<filename> kubectl config use-context default-systemThese files are used as follows:
| filename | command | comment |
|---|---|---|
| admin.conf | kubectl | Configures administrator user for the cluster |
| kubelet.conf | kubelet | One required for each node in the cluster. |
| controller-manager.conf | kube-controller-manager | Must be added to manifest in manifests/kube-controller-manager.yaml |
| scheduler.conf | kube-scheduler | Must be added to manifest in manifests/kube-scheduler.yaml |
Feedback
Was this page helpful?
Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on Stack Overflow. Open an issue in the GitHub repo if you want to report a problem or suggest an improvement.