Kubernetes集群的安全配置
使用kubernetes/cluster/kube-up.sh脚本在装有Ubuntu操作系统的bare metal上搭建的Kubernetes集群并不安全,甚至可以说是“完全不设防的”,这是因为Kubernetes集群的核心组件:kube-apiserver启用了insecure-port。insecure-port背后的api server默认完全信任访问该端口的流量,内部无任何安全机制。并且监听insecure-port的api server bind的insecure-address为0.0.0.0。也就是说任何内外部请求,都可以通过insecure-port端口任意操作Kubernetes集群。我们的平台虽小,但“裸奔”的k8s集群也并不是我们想看到的,适当的安全配置是需要的。
在本文中,我将和大家一起学习一下Kubernetes提供的安全机制,并通过安全配置调整,实现K8s集群的“有限”安全。
一、集群现状
我们先来“回顾”一下集群现状,为后续配置调整提供一个可回溯和可比对的“基线”。
1、Nodes
集群基本信息:
# kubectl cluster-info
Kubernetes master is running at http://10.47.136.60:8080
KubeDNS is running at http://10.47.136.60:8080/api/v1/proxy/namespaces/kube-system/services/kube-dns
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
当前集群逻辑上由一个master node和两个worker nodes组成:
单master: 10.47.136.60
worker nodes: 10.47.136.60和10.46.181.146
# kubectl get node --show-labels=true
NAME STATUS AGE LABELS
10.46.181.146 Ready 41d beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=10.46.181.146
10.47.136.60 Ready 41d beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=10.47.136.60
2、kubernetes核心组件的启动参数
我们再来明确一下当前集群中各k8s核心组件的启动参数,这些参数决定着组件背后的行为:
master node & worker node1 – 10.47.136.60上:
root 22000 1 0 Oct17 ? 03:52:55 /opt/bin/kube-controller-manager --master=127.0.0.1:8080 --root-ca-file=/srv/kubernetes/ca.crt --service-account-private-key-file=/srv/kubernetes/server.key --logtostderr=true
root 22021 1 1 Oct17 ? 17:11:15 /opt/bin/kube-apiserver --insecure-bind-address=0.0.0.0 --insecure-port=8080 --etcd-servers=http://127.0.0.1:4001 --logtostderr=true --service-cluster-ip-range=192.168.3.0/24 --admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,SecurityContextDeny,ResourceQuota --service-node-port-range=30000-32767 --advertise-address=10.47.136.60 --client-ca-file=/srv/kubernetes/ca.crt --tls-cert-file=/srv/kubernetes/server.cert --tls-private-key-file=/srv/kubernetes/server.key
root 22121 1 0 Oct17 ? 00:22:30 /opt/bin/kube-scheduler --logtostderr=true --master=127.0.0.1:8080
root 2140405 1 0 Nov15 ? 00:05:26 /opt/bin/kube-proxy --hostname-override=10.47.136.60 --master=http://10.47.136.60:8080 --logtostderr=true
root 1912455 1 1 Nov15 ? 03:43:09 /opt/bin/kubelet --hostname-override=10.47.136.60 --api-servers=http://10.47.136.60:8080 --logtostderr=true --cluster-dns=192.168.3.10 --cluster-domain=cluster.local --config=
worker node2 – 10.46.181.146上:
root 7934 1 1 Nov15 ? 03:06:00 /opt/bin/kubelet --hostname-override=10.46.181.146 --api-servers=http://10.47.136.60:8080 --logtostderr=true --cluster-dns=192.168.3.10 --cluster-domain=cluster.local --config=
root 23026 1 0 Nov15 ? 00:04:49 /opt/bin/kube-proxy --hostname-override=10.46.181.146 --master=http://10.47.136.60:8080 --logtostderr=true
从master node的核心组件kube-apiserver 的启动命令行参数也可以看出我们在开篇处所提到的那样:apiserver insecure-port开启,且bind 0.0.0.0:8080,可以任意访问,连basic_auth都没有。当然api server不只是监听这一个端口,在api server源码中,我们可以看到默认情况下,apiserver还监听了另外一个secure port,该端口的默认值是6443,通过lsof命令查看6443端口的监听进程也可以印证这一点:
//master node上
# lsof -i tcp:6443
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
kube-apis 22021 root 46u IPv6 921529 0t0 TCP *:6443 (LISTEN)
3、私钥文件和公钥证书
通过安装脚本在bare-metal上安装的k8s集群,在master node上你会发现如下文件:
root@node1:/srv/kubernetes# ls
ca.crt kubecfg.crt kubecfg.key server.cert server.key
这些私钥文件和公钥证书是在k8s(1.3.7)集群安装过程由安装脚本创建的,在kubernetes/cluster/common.sh中你可以发现function create-certs这样一个函数,这些文件就是它创建的。
# Create certificate pairs for the cluster.
# $1: The public IP for the master.
#
# These are used for static cert distribution (e.g. static clustering) at
# cluster creation time. This will be obsoleted once we implement dynamic
# clustering.
#
# The following certificate pairs are created:
#
# - ca (the cluster's certificate authority)
# - server
# - kubelet
# - kubecfg (for kubectl)
#
# TODO(roberthbailey): Replace easyrsa with a simple Go program to generate
# the certs that we need.
#
# Assumed vars
# KUBE_TEMP
#
# Vars set:
# CERT_DIR
# CA_CERT_BASE64
# MASTER_CERT_BASE64
# MASTER_KEY_BASE64
# KUBELET_CERT_BASE64
# KUBELET_KEY_BASE64
# KUBECFG_CERT_BASE64
# KUBECFG_KEY_BASE64
function create-certs {
local -r primary_cn="${1}"
... ...
}
简单描述一下这些文件的用途:
- ca.crt:the cluster's certificate authority,CA证书,即根证书,内置CA公钥,用于验证某.crt文件,是否是CA签发的证书;
- server.cert:kube-apiserver服务端公钥数字证书;
- server.key:kube-apiserver服务端私钥文件;
- kubecfg.crt 和kubecfg.key:按照 create-certs函数注释中的说法:这两个文件是为kubectl访问apiserver[双向证书验证](http://tonybai.com/2015/04/30/go-and-https/)时使用的。
不过,这里我们没有CA的key,无法签发新证书,如果要用这几个文件,那么就仅能限于这几个文件。我们可以利用kubecfg.crt 和kubecfg.key 作为访问api server的client端的key和crt使用。我们来查看一下这几个文件:
查看ca.crt:
#openssl x509 -noout -text -in ca.crt
... ...
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 16946557986148168970 (0xeb2e44b3a1ebb50a)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=10.47.136.60@1476362758
Validity
Not Before: Oct 13 12:45:58 2016 GMT
Not After : Oct 11 12:45:58 2026 GMT
Subject: CN=10.47.136.60@1476362758
... ..
查看server.cert:
...
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=10.47.136.60@1476362758
Validity
Not Before: Oct 13 12:45:59 2016 GMT
Not After : Oct 11 12:45:59 2026 GMT
Subject: CN=kubernetes-master
...
查看kubecfg.crt:
...
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 2 (0x2)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=10.47.136.60@1476362758
Validity
Not Before: Oct 13 12:45:59 2016 GMT
Not After : Oct 11 12:45:59 2026 GMT
Subject: CN=kubecfg
...
再来验证一下server.cert和kubecfg.crt是否是ca.crt签发的:
# openssl verify -CAfile ca.crt kubecfg.crt
kubecfg.crt: OK
# openssl verify -CAfile ca.crt server.cert
server.cert: OK
在前面的apiserver的启动参数展示中,我们已经看到kube-apiserver使用了ca.crt, server.cert和server.key:
/opt/bin/kube-apiserver --insecure-bind-address=0.0.0.0 --insecure-port=8080 --etcd-servers=http://127.0.0.1:4001 --logtostderr=true --service-cluster-ip-range=192.168.3.0/24 --admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,SecurityContextDeny,ResourceQuota --service-node-port-range=30000-32767 --advertise-address=10.47.136.60 --client-ca-file=/srv/kubernetes/ca.crt --tls-cert-file=/srv/kubernetes/server.cert --tls-private-key-file=/srv/kubernetes/server.key
在后续章节中,我们还会详细说明这些密钥和公钥证书在K8s集群安全中所起到的作用。
二、集群环境
还是那句话,Kubernetes在active development中,老版本和新版本的安全机制可能有较大变动,本篇中的配置方案和步骤都是针对一定环境有效的,我们的环境如下:
OS:
Ubuntu 14.04.4 LTS Kernel:3.19.0-70-generic #78~14.04.1-Ubuntu SMP Fri Sep 23 17:39:18 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Docker:
# docker version
Client:
Version: 1.12.2
API version: 1.24
Go version: go1.6.3
Git commit: bb80604
Built: Tue Oct 11 17:00:50 2016
OS/Arch: linux/amd64
Server:
Version: 1.12.2
API version: 1.24
Go version: go1.6.3
Git commit: bb80604
Built: Tue Oct 11 17:00:50 2016
OS/Arch: linux/amd64
Kubernetes集群:1.3.7
私有镜像仓库:阿里云镜像仓库
三、目标
目前,我们尚不具备一步迈向“绝对安全”的能力,在目标设定时,我们的一致想法是在当前阶段“有限安全”的K8s集群更适合我们。在这一原则下,我们针对不同情况提出不同的目标设定。
前面说过,k8s针对insecure port(–insecure-bind-address=0.0.0.0 –insecure-port=8080)的流量没有任何安全机制限制,相当于k8s“裸奔”。但是走k8s apiserver secure port(–bind-address=0.0.0.0 –secure-port=6443)的流量,将会遇到验证、授权等安全机制的限制。具体使用哪个端口与API server的交互方式,要视情况而定。
在分情况说明之前,将api server的insecure port的bind address由0.0.0.0改为local address是必须要做的。
1、Cluster -> Master(apiserver)
从集群到Apiserver的流量也可以细分为几种情况:
a) kubernetes component on master node -> apiserver
由于master node上的components与apiserver运行在一台机器上,因此可以通过local address的insecure-port访问apiserver,无需走insecure port。从现状中当前master上的component组件的启动参数来看,目前已经符合要求,于是针对这些components,我们无需再做配置上的调整。
b) kubernetes component on worker node -> apiserver
目标是实现kubernetes components on worker node和运行于master上的apiserver之间的基于https的双向认证。kubernetes的各个组件均支持在命令行参数中传入tls相关参数,比如ca文件路径,比如client端的cert文件和key等。
c) componet in pod for kubernetes -> apiserver
像kube dns和kube dashboard这些运行于pod中的k8s 组件也是在k8s cluster范围内调度的,它们可能运行在任何一个worker node上。理想情况下,它们与master上api server的通信也应该是基于一定安全机制的。不过在本篇中,我们暂时不动它们的设置,以免对其他目标的实现造成一定障碍和更多的工作量,在后续文章中,可能会专门将dns和dashboard拿出来做安全加固说明。因此,dns和dashboard在这里仍然使用的是insecure-port:
root 10531 10515 0 Nov15 ? 00:03:02 /dashboard --port=9090 --apiserver-host=http://10.47.136.60:8080
root 2018255 2018240 0 Nov15 ? 00:03:50 /kube-dns --domain=cluster.local. --dns-port=10053 --kube-master-url=http://10.47.136.60:8080
d) user service in pod -> apiserver
我们的集群管理程序也是以service的形式运行在k8s cluster中的,这些程序如何访问apiserver才是我们关心的重点,我们希望管理程序通过secure-port,在一定的安全机制下与apiserver交互。
2、Master(apiserver) -> Cluster
apiserver作为client端访问Cluster,在k8s文档中,这个访问路径主要包含两种情况:
a) apiserver与各个node上kubelet交互,采集Pod的log;
b) apiserver通过自身的proxy功能访问node、pod以及集群中的各种service。
在“有限安全”的原则下,我们暂不考虑这种情况下的安全机制。
四、Kubernetes的安全机制
kube-apiserver是整个kubernetes集群的核心,无论是kubectl还是通过api管理集群,最终都会落到与kube-apiserver的交互,apiserver是集群管理命令的入口。kube-apiserver同时监听两个端口:insecure-port和secure-port。之前提到过:通过insecure-port进入apiserver的流量可以有控制整个集群的全部权限;而通过secure-port的流量将经过k8s的安全机制的重重考验,这也是这一节我们重要要说明的。insecure-port的存在一般是为了集群bootstrap或集群开发调试使用的。官方文档建议:集群外部流量都应该走secure port。insecure-port可通过firewall rule使外部流量unreachable。
下面这幅官方图示准确解释了通过secure port的流量将要通过的“安全关卡”:
我们可以看到外界到APIServer的请求先后经过了:
安全通道(tls) -> Authentication(身份验证) -> Authorization(授权)-> Admission Control(入口条件控制)
-
安全通道:即基于tls的https的安全通道建立,对流量进行加密,防止嗅探、身份冒充和篡改;
-
Authentication:即身份验证,这个环节它面对的输入是整个http request。它负责对来自client的请求进行身份校验,支持的方法包括:client证书验证(https双向验证)、basic auth、普通token以及jwt token(用于serviceaccount)。APIServer启动时,可以指定一种Authentication方法,也可以指定多种方法。如果指定了多种方法,那么APIServer将会逐个使用这些方法对客户端请求进行验证,只要请求数据通过其中一种方法的验证,APIServer就会认为Authentication成功;
-
Authorization:授权。这个阶段面对的输入是http request context中的各种属性,包括:user、group、request path(比如:/api/v1、/healthz、/version等)、request verb(比如:get、list、create等)。APIServer会将这些属性值与事先配置好的访问策略(access policy)相比较。APIServer支持多种authorization mode,包括AlwaysAllow、AlwaysDeny、ABAC、RBAC和Webhook。APIServer启动时,可以指定一种authorization mode,也可以指定多种authorization mode,如果是后者,只要Request通过了其中一种mode的授权,那么该环节的最终结果就是授权成功。
-
Admission Control:从技术的角度看,Admission control就像a chain of interceptors(拦截器链模式),它拦截那些已经顺利通过authentication和authorization的http请求。http请求沿着APIServer启动时配置的admission control chain顺序逐一被拦截和处理,如果某个interceptor拒绝了该http请求,那么request将会被直接reject掉,而不是像authentication或authorization那样有继续尝试其他interceptor的机会。
五、实现安全传输通道(https)与身份校验(authentication)
在建立安全传输通道、身份校验环节,我们根据”目标“设定一节中的分类,也分为三种情况:
a) 运行于master上的核心k8s components走insecure port,这个暂不用修改配置;
b) worker node上的k8s组件配置通过insecure-port访问,并采用https双向认证的身份验证机制;
c) pod in k8s访问apiserver,通过https+ basic auth的方式进行身份验证。
APIServer直接使用了集群创建时创建的ca.crt、server.cert和server.key,由于没有ca.key,所以我们只能直接利用其它两个文件: kubecfg.key和kubecfg.crt作为客户端的私钥文件和公钥证书。当然你也可以手动重新创建ca,并将apiserver使用的.key、.crt以及各个components的client.key和client.crt都生成一份,并用你生成的Ca签发。这里我们就偷个懒儿了。
在开始之前,我们再来看看apiserver的启动参数:
root 22021 1 1 Oct17 ? 17:11:15 /opt/bin/kube-apiserver --insecure-bind-address=0.0.0.0 --insecure-port=8080 --etcd-servers=http://127.0.0.1:4001 --logtostderr=true --service-cluster-ip-range=192.168.3.0/24 --admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,SecurityContextDeny,ResourceQuota --service-node-port-range=30000-32767 --advertise-address=10.47.136.60 --client-ca-file=/srv/kubernetes/ca.crt --tls-cert-file=/srv/kubernetes/server.cert --tls-private-key-file=/srv/kubernetes/server.key
由于之前简述了Kubernetes的安全机制,于是我们对这些参数又有了进一步认识
https安全通道建立阶段:端口6443(通过 /opt/bin/kube-apiserver --help查看options说明可以得到),公钥证书server.cert ,私钥文件:server.key。
Authentication阶段:从当前启动参数中,我们仅能看到一种机制:--client-ca-file=/srv/kubernetes/ca.crt,也就是client证书校验机制。apiserver会用/srv/kubernetes/ca.crt对client端发过来的client.crt进行验证。
Authorization阶段:通过 /opt/bin/kube-apiserver --help查看options说明可以得到:--authorization-mode="AlwaysAllow",也就是说在这一环节,所有Request都可以顺利通过。
Admission Control阶段:apiserver指定了“NamespaceLifecycle,LimitRanger,ServiceAccount,SecurityContextDeny,ResourceQuota”这样一个interceptor链。
我们首先来测试一下通过kubecfg.key和kubecfg.crt访问APIServer的insecure-port,验证一下kubecfg.key和kubecfg.crt作为client端私钥文件和公钥证书的可行性:
# curl https://10.47.136.60:6443/version --cert /srv/kubernetes/kubecfg.crt --key /srv/kubernetes/kubecfg.key --cacert /srv/kubernetes/ca.crt
{
"major": "1",
"minor": "3",
"gitVersion": "v1.3.7",
"gitCommit": "a2cba278cba1f6881bb0a7704d9cac6fca6ed435",
"gitTreeState": "clean",
"buildDate": "2016-09-12T23:08:43Z",
"goVersion": "go1.6.2",
"compiler": "gc",
"platform": "linux/amd64"
}
接下来,我们就来开始调整k8s配置。
第一个场景:components on worker node -> master
worker node上有两个k8s components:kubelet和kube-proxy,当前它们的启动参数为:
root 7934 1 1 Nov15 ? 03:33:35 /opt/bin/kubelet --hostname-override=10.46.181.146 --api-servers=http://10.47.136.60:8080 --logtostderr=true --cluster-dns=192.168.3.10 --cluster-domain=cluster.local --config=
root 8140 1 0 14:59 ? 00:00:00 /opt/bin/kube-proxy --hostname-override=10.46.181.146 --master=http://10.47.136.60:8080 --logtostderr=true
我们将ca.crt、kubecfg.key和kubecfg.crt scp到其他各个Worker node的/srv/kubernetes目录下:
root@node1:/srv/kubernetes# scp ca.crt root@10.46.181.146:/srv/kubernetes
ca.crt 100% 1220 1.2KB/s 00:00
root@node1:/srv/kubernetes# scp kubecfg.crt root@10.46.181.146:/srv/kubernetes
kubecfg.crt 100% 4417 4.3KB/s 00:00
root@node1:/srv/kubernetes# scp kubecfg.key root@10.46.181.146:/srv/kubernetes
kubecfg.key
在worker node: 10.46.181.146上:
# ls -l
total 16
-rw-r----- 1 root root 1220 Nov 25 15:51 ca.crt
-rw------- 1 root root 4417 Nov 25 15:51 kubecfg.crt
-rw------- 1 root root 1708 Nov 25 15:51 kubecfg.key
创建worker node上kubelet和kube-proxy所要使用的config文件:/root/.kube/config
/root/.kube/config
apiVersion: v1
kind: Config
preferences: {}
users:
- name: kubecfg
user:
client-certificate: /srv/kubernetes/kubecfg.crt
client-key: /srv/kubernetes/kubecfg.key
clusters:
- cluster:
certificate-authority: /srv/kubernetes/ca.crt
name: ubuntu
contexts:
- context:
cluster: ubuntu
user: kubecfg
name: ubuntu
current-context: ubuntu
这个文件参考了master node上的/root/.kube/config文件的格式,你也可以在master node上使用kubectl config view查看config文件内容:
# kubectl config view
apiVersion: v1
clusters:
- cluster:
insecure-skip-tls-verify: true
server: http://10.47.136.60:8080
name: ubuntu
contexts:
- context:
cluster: ubuntu
user: ubuntu
name: ubuntu
current-context: ubuntu
kind: Config
preferences: {}
users:
- name: ubuntu
user:
password: xxxxxA
username: admin
Worker node上/root/.kube/config中的user.name使用的是kubecfg,这也是在前面查看kubecfg.crt时,kubecfg.crt在/CN域中使用的值。
接下来我们来修改worker node上的/etc/default/kubelet文件:
KUBELET_OPTS=" --hostname-override=10.46.181.146 --api-servers=https://10.47.136.60:6443 --logtostderr=true --cluster-dns=192.168.3.10 --cluster-domain=cluster.local --kubeconfig=/root/.kube/config"
#KUBELET_OPTS=" --hostname-override=10.46.181.146 --api-servers=http://10.47.136.60:8080 --logtostderr=true --cluster-dns=192.168.3.10 --cluster-domain=cluster.local --config= "
在worker node上重启kubelet并查看/var/log/upstart/kubelet.log:
# service kubelet restart
kubelet stop/waiting
kubelet start/running, process 9716
///var/log/upstart/kubelet.log
... ...
I1125 16:12:26.332652 9716 server.go:784] Watching apiserver
W1125 16:12:26.338581 9716 kubelet.go:572] Hairpin mode set to "promiscuous-bridge" but configureCBR0 is false, falling back to "hairpin-veth"
I1125 16:12:26.338641 9716 kubelet.go:393] Hairpin mode set to "hairpin-veth"
I1125 16:12:26.366600 9716 docker_manager.go:235] Setting dockerRoot to /var/lib/docker
I1125 16:12:26.367067 9716 server.go:746] Started kubelet v1.3.7
E1125 16:12:26.369508 9716 kubelet.go:954] Image garbage collection failed: unable to find data for container /
I1125 16:12:26.370534 9716 fs_resource_analyzer.go:66] Starting FS ResourceAnalyzer
I1125 16:12:26.370567 9716 status_manager.go:123] Starting to sync pod status with apiserver
I1125 16:12:26.370601 9716 kubelet.go:2501] Starting kubelet main sync loop.
I1125 16:12:26.370632 9716 kubelet.go:2510] skipping pod synchronization - [network state unknown container runtime is down]
I1125 16:12:26.370981 9716 server.go:117] Starting to listen on 0.0.0.0:10250
I1125 16:12:26.384336 9716 volume_manager.go:227] Starting Kubelet Volume Manager
I1125 16:12:26.480387 9716 factory.go:295] Registering Docker factory
I1125 16:12:26.480483 9716 factory.go:54] Registering systemd factory
I1125 16:12:26.481446 9716 factory.go:86] Registering Raw factory
I1125 16:12:26.482888 9716 manager.go:1072] Started watching for new ooms in manager
I1125 16:12:26.484242 9716 oomparser.go:200] OOM parser using kernel log file: "/var/log/kern.log"
I1125 16:12:26.485330 9716 manager.go:281] Starting recovery of all containers
I1125 16:12:26.562959 9716 kubelet.go:1213] Node 10.46.181.146 was previously registered
I1125 16:12:26.712150 9716 manager.go:286] Recovery completed
一次点亮!
再来修改worker node上kube-proxy的配置:/etc/default/kube-proxy:
// /etc/default/kube-proxy
KUBE_PROXY_OPTS=" --hostname-override=10.46.181.146 --master=https://10.47.136.60:6443 --logtostderr=true --kubeconfig=/root/.kube/config"
#KUBE_PROXY_OPTS=" --hostname-override=10.46.181.146 --master=http://10.47.136.60:8080 --logtostderr=true "
在worker node上重启kube-proxy并查看/var/log/upstart/kube-proxy.log:
# service kube-proxy restart
kube-proxy stop/waiting
kube-proxy start/running, process 26185
// /var/log/upstart/kube-proxy.log
I1125 16:30:28.224491 26185 server.go:202] Using iptables Proxier.
I1125 16:30:28.228067 26185 server.go:214] Tearing down userspace rules.
I1125 16:30:28.245634 26185 conntrack.go:40] Setting nf_conntrack_max to 65536
I1125 16:30:28.247422 26185 conntrack.go:57] Setting conntrack hashsize to 16384
I1125 16:30:28.249456 26185 conntrack.go:62] Setting nf_conntrack_tcp_timeout_established to 86400
从日志上看不出有啥异常,算是成功!:)
第二个场景:pod in cluster -> master
通过阅读K8s的官方文档“Accessing the api from a pod”,我们知道K8s cluster为Pod访问API Server做了很多“预备”工作,最重要的一点就是在Pod被创建的时候,一个serviceaccount 被自动mount到/var/run/secrets/kubernetes.io/serviceaccount路径下:
#kubectl describe pod/my-golang-1147314274-0qms5
Name: my-golang-1147314274-0qms5
Namespace: default
Node: 10.47.136.60/10.47.136.60
Start Time: Thu, 24 Nov 2016 14:59:52 +0800
Labels: pod-template-hash=1147314274
run=my-golang
Status: Running
IP: 172.16.99.9
... ...
Containers:
my-golang:
... ...
Volume Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-40z0x (ro)
Environment Variables: <none>
... ...
Volumes:
default-token-40z0x:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-40z0x
QoS Class: BestEffort
Tolerations: <none>
serviceaccount顾名思义,是Pod中程序访问APIServer所要使用的账户信息,我们来看看都有啥:
# kubectl get serviceaccount
NAME SECRETS AGE
default 1 43d
# kubectl describe serviceaccount/default
Name: default
Namespace: default
Labels: <none>
Image pull secrets: <none>
Mountable secrets: default-token-40z0x
Tokens: default-token-40z0x
# kubectl describe secret/default-token-40z0x
Name: default-token-40z0x
Namespace: default
Labels: <none>
Annotations: kubernetes.io/service-account.name=default
kubernetes.io/service-account.uid=90de59ad-9120-11e6-a0a6-00163e1625a9
Type: kubernetes.io/service-account-token
Data
====
ca.crt: 1220 bytes
namespace: 7 bytes
token: {Token data}
mount到Pod中/var/run/secrets/kubernetes.io/serviceaccount路径下的default-token-40z0x volume包含三个文件:
- ca.crt:CA的公钥证书
- namspace文件:里面的内容为:”default”
- token:用在Pod访问APIServer时候的身份验证。
理论上,使用这些信息Pod可以成功访问APIServer,我们来测试一下。注意在Pod的世界中,APIServer也是一个Service,通过kubectl get service可以看到:
# kubectl get services
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes 192.168.3.1 <none> 443/TCP 43d
kubernetes这个Service监听的端口是443,也就是说在Pod的视角中,APIServer暴露的仅仅是insecure-port。并且使用”kubernetes”这个名字,我们可以通过kube-dns获得APIServer的ClusterIP。
启动一个基于golang:latest的pod,pod.yaml如下:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: my-golang
spec:
replicas: 1
template:
metadata:
labels:
run: my-golang
spec:
containers:
- name: my-golang
image: golang:latest
command: ["tail", "-f", "/var/log/bootstrap.log"]
Pod启动后,docker exec -it container-id /bin/bash切入container,并执行如下命令:
# TOKEN="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)"
# curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt https://kubernetes:443/version -H "Authorization: Bearer $TOKEN"
Unauthorized
查看API Server的log:
E1125 17:30:22.504059 2743425 handlers.go:54] Unable to authenticate the request due to an error: crypto/rsa: verification error
似乎是验证token失败。这个问题在kubernetes的github issue中也有被提及,目前尚未解决。
不过仔细想了想,如果每个Pod都默认可以访问APIServer,显然也是不安全的,虽然我们可以通过authority和admission control对默认的token访问做出限制,但总感觉不那么“安全”。
我们来试试basic auth方式(这种方式的弊端是API Server运行中,无法在运行时动态更新auth文件,对于auth文件的修改,必须重启APIServer后生效)。
我们首先在APIServer侧为APIServer创建一个basic auth file:
// /srv/kubernetes/basic_auth_file
admin123,admin,admin
basic_auth_file中每一行的格式:password,username,useruid
修改APIServer的启动参数,将basic_auth_file传入并重启apiserver:
KUBE_APISERVER_OPTS=" --insecure-bind-address=10.47.136.60 --insecure-port=8080 --etcd-servers=http://127.0.0.1:4001 --logtostderr=true --service-cluster-ip-range=192.168.3.0/24 --admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,SecurityContextDeny,ResourceQuota --service-node-port-range=30000-32767 --advertise-address=10.47.136.60 --basic-auth-file=/srv/kubernetes/basic_auth_file --client-ca-file=/srv/kubernetes/ca.crt --tls-cert-file=/srv/kubernetes/server.cert --tls-private-key-file=/srv/kubernetes/server.key"
我们在Pod中使用basic auth访问API Server:
# curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt https://kubernetes:443/version -basic -u admin:admin123
{
"major": "1",
"minor": "3",
"gitVersion": "v1.3.7",
"gitCommit": "a2cba278cba1f6881bb0a7704d9cac6fca6ed435",
"gitTreeState": "clean",
"buildDate": "2016-09-12T23:08:43Z",
"goVersion": "go1.6.2",
"compiler": "gc",
"platform": "linux/amd64"
}
Pod to APIServer authentication成功了。
六、小结
再重申一次:上述配置不是绝对安全的理想配置方案,只是阶段性满足我目前项目需求的一个“有限安全”方案,大家谨慎参考。
到目前为止,我们的“有限安全”也仅仅做到Authentication这一步,至于Authority和Admission Control,目前尚未有相关实践,可能会在后续的文章中做单独说明。
七、参考资料
- Master <-> Node Communication – http://kubernetes.io/docs/admin/master-node-communication/
- Authentication – http://kubernetes.io/docs/admin/authentication/
- Using Authorization Plugins – http://kubernetes.io/docs/admin/authorization/
- Accessing the API – http://kubernetes.io/docs/admin/accessing-the-api/
- Managing Service Accounts – http://kubernetes.io/docs/admin/service-accounts-admin/
- Authenticating Across Clusters with kubeconfig — http://kubernetes.io/docs/user-guide/kubeconfig-file/
- Service Accounts — https://docs.openshift.com/enterprise/3.1/dev_guide/service_accounts.html
- 4S: SERVICES ACCOUNT, SECRET, SECURITY CONTEXT AND SECURITY IN KUBERNETES — http://www.sel.zju.edu.cn/?p=588
- KUBERNETES APISERVER源码分析——API请求的认证过程 – http://www.sel.zju.edu.cn/?p=609
- Kubernetes安全配置案例 – http://www.cnblogs.com/breg/p/5923604.html
评论