The Kubernetes system provides three authentication methods: CA authentication, Token authentication, and Base authentication. A security feature is a double-edged sword, it protects the system from attack, but it also brings additional performance penalty. When each component in the cluster accesses the API Server, since they are in the same local area network with the API Server, it is recommended to use the non-secure way to access the API Server to be more efficient.
Next, the two-way authentication configuration and simple authentication configuration process of the cluster are described in detail.
Two-way authentication configuration
The two-way authentication method is the most strict and secure cluster security configuration method. The main configuration process is as follows:
- Generate root certificate, API Server server certificate, server private key, client certificate and client private key used by each component.
- Modify the startup parameters of each Kubernetes service process to enable the two-way authentication mode.
The detailed configuration operation process is as follows:
Generate root certificate
Use the openssl tool to generate the CA certificate, please note that the parameters such as subject are changed to the data required by the user, and the value of CN is usually the domain name, host name or IP address.
$ cd /var/run/kubernetes
$ openssl genrsa -out dd_ca.key 2048
$ openssl req -x509 -new -nodes -key dd_ca.key -subj "/CN=YOUDOMAIN.COM" -days 5000 -out dd_ca.crt
Generate API Server server certificate and private key
$ openssl genrsa -out dd_server.key 2048
$ HN=`hostname`
$ openssl req -new -key dd_server.key -subj "/CN=$HN" -out dd_server.csr $ openssl x509 -req -in dd_server.csr -CA dd_ca.crt -CAkey dd_ca.key -CAcreateserial-out dd_server.crt -days 5000
Generate the certificate and private key shared by Controller Manager and Scheduler process
$ openssl genrsa -out dd_cs_client.key 2048
$ openssl req -new -key dd_cs_client.key -subj "/CN=$HN" -out dd_cs_client.csr $ openssl x509 -req -in dd_cs_client.csr -CA dd_ca.crt -CAkey dd_ca.key -CAcreateserial -out dd_cs_client.crt -days 5000
Generate the client certificate and private key used by the Kubelet
Note that the IP address of the machine where the Kubelet resides is assumed to be 192.168.1.129.
$ openssl genrsa -out dd_kubelet_client.key 2048
$ openssl req -new -key dd_kubelet_client.key -subj "/CN=192.168.1.129" -out dd_kubelet_client.csr $ openssl x509 -req -in dd_kubelet_client.csr -CA dd_ca.crt -CAkey dd_ca.key -CAcreateserial -out dd_kubelet_client.crt -days 5000
Modify the startup parameters of API Server
Add parameters such as CA root certificate, Server's own certificate and set the secure port to 443.
Modify the KUBE_API_ARGS parameter of the /etc/kubernetes/apiserver configuration file:
KUBE_API_ARGS="--log-dir=/var/log/kubernetes --secure-port=443 --client_ca_file=/var/run/kubernetes/dd_ca.crt --tls-private-key-file=/var/run/kubernetes/dd_server.key --tls-cert-file=/var/run/kubernetes/dd_server.crt"
Restart the kube-apiserver service:
# systemctl restart kube-apiserver
Verify the API Server's HTTPS service.
$ curl https://kubernetes-master:443/api/v1/nodes --cert /var/run/kubernetes/dd_cs_client.crt --key /var/run/kubernetes/dd_cs_client.key --cacert /var/run/kubernetes/dd_ca.crt
Modify the startup parameters of Controller Manager
Modify the /etc/kubernetes/controller-manager configuration file
KUBE_CONTROLLER_MANAGER_ARGS="--log-dir=/var/log/kubernetes --service_account_private_key_file=/var/run/kubernetes/server.key --root-ca-file=/var/run/kubernetes/ca.crt --master=https://kubernetes-master:443 --kubeconfig=/etc/kubernetes/cmkubeconfig"
Create /etc/kubernetes/cmkubeconfig file, configure certificate and other related parameters, the details are as follows:
apiVersion: v1
kind: Config
users
- name: controllermanager
user:
client-certificate: /var/run/kubernetes/dd_cs_client.crt
client-key: /var/run/kubernetes/dd_cs_client.key
clusters:
- name: local cluster: certificate-authority: /var/run/kubernetes/dd_ca.crt contexts: - context: cluster: local user: controllermanager name: my-context current-context: my-context
Restart the kube-controller-manager service:
# systemctl restart kube-controller-manager
配置各个节点上的 Kubelet 进程
复制 Kubelet 的证书、私钥 与 CA 根证书到所有 Node 上。
$ scp /var/run/kubernetes/dd_kubelet* root@kubernetes-minion1:/home
$ scp /var/run/kubernetes/dd_ca.* root@kubernetes-minion:/home
在每个 Node 上创建/var/lib/kubelet/kubeconfig 文件,内容如下:
apiVersion: v1
kind: Config
users:
- name: kubelet
user:
client-certificats: /home/dd_kubelet_client.crt
client-key: /home/dd_kubelet_client.key
clusters:
- name: local
cluster:
certificate-authority: /home/dd_ca.crt
contexts:
- context:
cluster: local user: kubelet name: my-context current-context: my-context
修改 Kubelet 的启动参数,以修改/etc/kubernetes/kubelet 配置文件为例:
KUBELET_API_SERVER="--api_servers=https://kubernetes-master:443"
KUBELET_ARGS="--pod_infro_container_image=192.168.1.128:1180/google_containers/pause:latest --cluster_dns=10.2.0.100 --cluster_domain=cluster.local --kubeconfig=/var/lib/kubelet/kubeconfig"
重启 kubelet 服务:
# systemctl restart kubelet
配置 kube-proxy
首先,创建/var/lib/kubeproxy/proxykubeconfig 文件,内容如下:
apiVersion: v1
kind: Config
users:
- name: kubeproxy
user:
client-certificate: /home/dd_kubelet_client.crt
client-key: /home/dd_kubelet_client.key
clusters:
- name: local
cluster:
certificate-authority: /home/dd_ca.crt
contexts:
- context:
cluster: local user: kubeproxy name: my-context current-context: my-context
然后,修改 kube-proxy 的启动参数,引用上述文件并指明 API Server 在安全模式下的访问地址,以修改配置文件/etc/kubenetes/proxy 为例:
KUBE_PROXY_ARGS="--kubeconfig=/var/lib/kubeproxy/proxykubeconfig --master=https://kubenetes-master:443"
重启 kube-proxy 服务:
# systemctl restart kube-proxy
至此,一个双向认证的 Kubernetes 集群环境就搭建完成了。
简单认证配置
除了双向认证方式,Kubernets 也提供了基于 Token 和 HTTP Base 的简单认证方式。通信方式仍然采用 HTTPS,但不使用数字证书。
采用基于 Token 和 HTTP Base 的简单认证方式时,API Server 对外暴露 HTTPS 端口,客户端提供 Token 或用户名、密码来完成认证过程。这里需要说明的一点是 Kubelet 比较特殊,它同时支持双向认证与简单认证两种模式,其他组件智能配置为双向认证或非安全模式。
API Server 基于 Token 认证的配置过程如下
建立包括用户名、密码和 UID 的文件 token_auth_file:
$ cat /root/token_auth_file
dingmingk,dingmingk,1
admin,admin,2
system,system,3
修改 API Server 的配置,采用上述文件进行安全认证
$ vi /etc/kubernetes/apiserver
KUBE_API_ARGS="--secure-port=443 --token_auth_file=/root/token_auth_file"
重启 API Server 服务
# systemctl restart kube-apiserver
用 curl 验证连接 API Server
$ curl https://kubenetes-master:443/version --header "Authorization: Bearer dingmingk" -k
{
"major": "1", "minor": "0", "gitVersion": "v1.0.0", "gitCommit": "xxxHASHCODE", "gitTreeState": "clean" }
API Server 基于 HTTP Base 认证的配置过程如下
创建包括用户名、密码和 UID 的文件 basic_auth_file:
$ cat /root/basic_auth_file
dingmingk,dingmingk,1
admin,admin,2
system,system,3
修改 API Server 的配置,采用上述文件进行安全认证
$ vi /etc/kubernetes/apiserver
KUBE_API_ARGS="--secure-port=443 --basic_auth_file=/root/basic_auth_file"
重启 API Server 服务
# systemctl restart kube-apiserver
用 curl 验证连接 API Server
$ curl https://kubernetes-master:443/version --basic -u dingmingk:dingmingk -k
{
"major": "1", "minor": "0", "gitVersion": "v1.0.0", "gitCommit": "xxxHASHCODE", "gitTreeState": "clean" }
使用 Kubelet 时则需要指定用户名和密码来访问 API Server
$ kubectl get nodes --server="https://kubernetes-master:443" --api-version="v1" --username="dingmingk" --password="dingmingk" --insecure-skip-tls-verify=true
kubectl config set-cluster
在kubeconfig配置文件中设置一个集群项。
摘要
在kubeconfig配置文件中设置一个集群项。 如果指定了一个已存在的名字,将合并新字段并覆盖旧字段。
示例
选项
继承自父命令的选项