简介
kubernetes作为一个分布式集群的管理工具,保证集群的安全性是一个重要的任务,API Server是集群内部各个组件通信的中介,也是外部控制的入口,所以Kubernetes的安全机制基本就是围绕保护API Server来设计的。
Kubernetes使用了认证(Authentication),鉴权(Autjorization),准入控制(AdmissionControl)三步来保证API Server的安全
认证(Authentication)
HTTP Token认证:通过一个Token认证来识别合法用户,用一个很长的特殊编码方式并且难以被模仿的字符串,Token来表达客户的一种方式,每一个Token对应一个用户名存储在API Server能访问的文件中,当客户端发起API调用请求时,需要在HTTP Header里放入Token
HTTP Base认证:通过用户名+密码的方式认证,用base64算法进行编码后的字符串放在HTTP Request中的Heather Autjorization域里发送给服务端,服务端收到后进行编码,获取用户名及密码
HTTPS证书认证:基于CA根证书签名的客户端身份认证方式
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
HTTPS证书认证
两种类型:
- Kubernetes组件对API Server的访问:kubectl,Controller Manger,Scheduler,kubelet,kube-proxy
- Kubernetes管理的Pod对容器的访问:Pod(dashboard也是以Pod形式运行)
安全性说明:
- Controller Manager,Scheduler与API Server在同一台机器,所以直接使用API Server的非安全端口访问,--insecure-bind-address=127.0.0.1
- kubectl,kubelet,kube-proxy访问API Server就都需要证书进行HTTPS双向认证
证书颁发:
- 手动签发:通过k8s集群的跟ca进行签发HTTPS证书
- 自动签发:kubelet首次访问API Server时,使用Token做认证,通过后,Controller Manager会为kubelet生成一个证书
kubeconfig
kubeconfig文件包含集群参数(CA证书,API Server地址),客户端参数(上面生成的证书和私钥),集群context信息(集群名称,用户名)。Kubernetes组件通过启动时指定不同的kubeconfig文件可以切换到不同的集群
ServiceAccount
Pod中的容器访问API Server,因为Pod的创建,销毁是动态的,所以要为它手动生成证书就不可行了,Kubernetes使用了ServiceAccount解决Pod访问API Server的认证问题
Secret与SA的关系
Kubernetes设计了一种资源对象叫做Secret分为两类,一种是用于ServiceAccount的service-account-token,另一种是用于保存用户自定义保密信息的Opaque。ServiceAccount中用到包含三个部分:Token,ca.crt,namespace
- token是使用API Server私钥签名的JWT,用于访问APIServer时,Server端认证
- ca.crt根证书,用于Client端验证API Server发送的证书
- namespace标识这个service-account-token的作用域名空间
授权(Authorization)
上面的认证过程只是确认通信的双方都确认了对方是可信的,可以相互通信,而鉴权是确定请求方由哪些资源的权限,API Server目前支持以下几种授权策略(通过API Server的启动参数“--authorization-mode”设置)
- AlwaysDerry:表示拒绝所有的请求,一般用于测试
- AlwaysAllow:允许接收所有的请求,如果集群不需要授权流程,则可以采用该策略
- ABAC(Attribute-Based Access Control):基于属性的访问控制,表示使用用户配置的授权规则对用户请求进行匹配和控制
- Webook:通过调用外部REST服务对用户进行授权
- RBAC(Role-Based Access Control):基于角色的访问控制,现行默认规则
RBAC授权模式
RBAC基于角色的访问控制,在Kubernetes1.5中引入,现行版蹦成为默认标准,相对其他的访问控制方式,拥有以下优势:
- 对集群中的资源和非资源拥有完整的覆盖
- 整个RBAC完全由几个API对象完成,同其他API对象一样,可以用kubectl或API进行操作
- 可以运行时进行调整,无需重启API Server
RBAC引入了4个新的顶级资源对象:Role,ClusterRole,RoleBinding,ClusterRoleBinding4种对象类型均可以通过kubectl和API操作
Kubernetes并不会提供用户管理,User,Group,ServiceAccount指定的用户向CA申请证书时,需要提供一个证书请求文件
{
"CN": "admin",
"hosts:" [],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"ST": "HangZhou",
"L": "XS",
"O": "system:masters",
"OU": "System"
}
]
}
CN字段作为User,names.O字段作为Group
Role and ClusterRole
在RBAC API中,Role表示一组规则权限,权限只会增加(累加权限),不存在一个资源一开始就有很多权限而通过RBAC对其进行减少的操作,Role可以定义在一个namespace中,如果想要跨namespace则可以创建ClusterRole
eg:
apiVerison: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
name: pod-reader
namespace: default
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get","watch","list"]
ClusterRole具有与Role相同的权限角色控制能力,不同的是ClusterRole是集群级别的,ClusterRole可以用于:
- 集群级别的资源控制(如:node访问权限)
- 非资源型endpoints(如:/healthz访问)
- 所有命名空间资源控制( 如:Pods)
eg:
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
name: secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get","watch","list"]
RoleBinding and ClusterRoleBinding
RoleBinding可以将角色中定义的权限授予用户或用户组,RoleBinding包含一组权限列表(subjects),权限列表中包含有不同形式的待授予权限资源类型(user,groups,or service accounts);RoloBinding同样包含对被Bind的Role引用;RoleBinding适用于某个命名空间内授权,而ClusterRoleBinding适用于集群范围内的授权
eg:
将default命名空间的pod-reader Role授予jane用户,此后jane用户在default命名空间中将具有pod-reader的权限
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
- kind: User
name: jane
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
RoleBinding同样可以引用ClusterRole来对当前namespace内用户,用户组或ServiceAccount进行授权,这种操作允许集群管理员在整个集群内定义一些通用的ClusterRole,然后在不同的namespace中使用RoleBinding来引用
eg:
RoleBinding引用了一个ClusterRole,这个ClusterRole具有整个集群内对secrets的访问权限;但是其授权用户dave只能访问development空间的secrets(因为RoleBinding定义在development命名空间)
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
name: read-secrets
namespace: development
subjects:
- kind: User
name: dave
apiGroup: rbac.authoruzation.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io
授权manager组内所有用户在全部命名空间中队secrets进行访问
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: read-secrets-global
subjects:
- kind: Group
name: manager
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io
实践:
创建一个用户只能管理dev空间
# vim devuser-csr.json
{
"CN": "devuser",
"hosts": [],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"ST": "BeiJing",
"L": "BeiJing",
"O": "k8s",
"OU": "System"
}
]
}
下载证书生成工具
# wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
# mv cfssl_linux-amd64 /usr/local/bin/cfssl
# wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
# mv cfssljson_linux-amd64 /usr/local/bin/cfssjson
# wget https://pkg.cfssl.org/R1.2/cfssl.org/R1.2/cfssl-certinfo_linux-amd64
# mv cfssl-certinfo_linux-amd64 /usr/local/bin/cfssl-certinfo
# cfssl gencert -ca=ca.crt -ca-key=ca.key -profile=kubernetes /root/devuser-csr.json | cfssljson -bare devuser
设置集群参数
# export KUBE_APISERVER="https://192.168.3.2:6443"
# kubectl config set-set-cluster kubernetes \
--certificate-authority=/etc/kubernetes/ssl/ca.pem \
--embed-certs=true \
--server=${KUBE_APISERVER} \
--kubeconfig=devuser.kubeconfig
设置客户端认证参数
# kubectl config set-credentials devuser \
--client-certificate=/etc/kubernetes/ssl/devuser.pem \
--embed-certs=true \
--kubeconfig=devuser.kubeconfig
设置上下文参数
kubectl config set-context kubernetes \
--cluster=kubernetes \
--user=devuser \
--namespace= dev \
kubeconfig=devuser.kubeconfig
设置默认上下文
# kubectl config use-context kubernetes --kubeconfig=devuser.kubeconfig
# cp -f ./devuser.kubeconfig /root/.kube/config
# kubectl create rolebinding devuser-admin-binding --clusterrole-admin --user=devuser --namespace=dev