文章目录
1. kubernetes API 访问控制
官方文档:
https://kubernetes.io/zh/docs/reference/access-authn-authz/controlling-access/
kubernetes api分为:认证
、授权
、准入控制
用户通过 kubectl、客户端库或者通过发送 REST 请求访问 API。 用户(自然人)和 Kubernetes 服务账户 都可以被授权进行 API 访问。 请求到达 API 服务器后会经过几个阶段,具体说明如图:
由上图来介绍一下 Kubernetes API 的请求从发起到其持久化入库 的一个流程。
首先看一下请求的发起,请求的发起分为两个部分:
- 第一个部分是人机交互的过程。 是大家非常熟悉的用 kubectl 对 apiserver 的一个请求过程;
- 第二个部分是 Pod 中的业务逻辑与 apiserver 之间的交互。
当我们的 apiserver 收到请求后,就会开启访问控制流程。这里面分为三个步骤:
- Authentication 认证阶段:判断请求用户是否为能够访问集群的合法用户。如果用户是个非法用户,那 apiserver会返回一个 401 的状态码,并终止该请求;
- 如果用户合法的话,我们的 apiserver 会进入到访问控制的第二阶段 Authorization:授权阶段。在该阶段中apiserver 会判断用户是否有权限进行请求中的操作。如果无权进行操作,apiserver 会返回 403的状态码,并同样终止该请求;
- 如果用户有权进行该操作的话,访问控制会进入到第三个阶段:AdmissionControl。在该阶段中 apiserver 的admission controller 会判断请求是否是一个安全合规的请求。如果最终验证通过的话,访问控制流程才会结束。
此时我们的请求将会转换为一个 Kubernetes objects 相应的变更请求,最终持久化到 ETCD 中。
认证(任意一种) -->授权(一般是rbac 和 node)–> 准入控制(自己选择)
2. 认证 Authentication
认证一共有8种,可以启动一种或多种认证方式,只要有一种认证方式通过,就不再对其它方式认证,通常启动X 509 Client Certs
和Service Accout Tokens
两种认证方式
k8s集群有两类用户: 由k8s管理的Service Accounts 服务帐号和 Users Accounts普通账户,k8s种的帐号是形式上存在的。
默认存在的taken:
1 访问k8s的API Server的客户端
访问k8s的API Server的客户端主要分为两类:
- kubectl :用户家目录中的
.kube/config
里面保存了客户端访问API Server的密钥相关信息,这样当用kubectl访问k8s时,它就会自动读取该配置文件,向API Server发起认证,然后完成操作请求。 - pod:Pod中的进程需要访问API Server,如果是人去访问或编写的脚本去访问,这类访问使用的账号为:
UserAccount
;而Pod自身去连接API Server时,使用的账号是:ServiceAccount
,生产中后者使用居多。
[kubeadm@server1 ~]$ cd .kube/ // 用户主目录下的认证文件
[kubeadm@server1 .kube]$ ls
cache config http-cache
[kubeadm@server1 .kube]$ cat config
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN5RENDQWJDZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJd01EUXhOekV5TWprME5Wb1hEVE13TURReE5URXlNamswTlZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTndICnI0cmVweEEzVTdpRXlkb3MwSHU4WmM5QnBGZW5ocVdwMjgxdmJQNUNOUEkxbG15R2J0V3l2TFBZdTk4UHVXK2YKTFhleEd4bUQvUm9nZmo0UVhYaDBRbTBKVlN6dEZIeFRnb1VobEgyd2REd0JhSFAxaUpybm5CNmx0c2tRZjVIaApPanhXVUtYVWtEZkxHcllRM3dzV0c5T1oxNDI0MEViUko3Q1NBUkwxd1ZkdDc5djZmNHRCUnRtWEN4SUFFUnFHCmpwRVJDMFh4ZU8xMU9rQTA1SjlJNjRHNXpybkxvOHVYV3JyaE5kOE53V3V6d3NQZ1F2V3NaejVudElHd3haR1QKcURjN25lMXU1c01TcHZMZG03UjgreHVIemxiZkpKNDdkSjc3QURXZXZ4WnY1UkNUeE5mSm9lOXpkdUNoV2pLdQpmWFNONXpKVUV3K25OSjJWOFFrQ0F3RUFBYU1qTUNFd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFCV3FpSnVKZXRyQmZ4NWtFb3NaUlYySXMyeEEKMWRhdW43WlJGbHYvT0xDTzJaZWVJNnlTRWpHU1hkWXpYZUREbnFoWHh0cy8zOFkvaVNXSFY3Z1JEdTJxbXpnZgp3a0hoK1pwci80WHgxMm5rL011dFRBUjNwMmJHRkFDM2djNUh1YWFma2ZnNldvc1ArdklxSkFjdXFjbkxqenZwCm5TVjlON0Y3dnNVeXdtSmIrV3hMaXY2VmgzbFRQMUJuck15aG5iVFA5bHhvK0hEOU9wUC9yTStvcEw0NXhrb0wKOXgrWHo5RXpDR29RUXpFT09nZUg3WW1tUFlvSXUzY0FKOG10dGtGNHpzTHRid1RiT2J2bGhsYmFqbWY4VXNEagptYnA4Vm0rYVNrS0p4SWhPVXlGcHlxQWRTQ3dxYUpjajNuQlRPdWJmV1VIeHAvYzI4dmladjRaVHA0az0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
kubectl 向 apiserver发起的命令,采用的时http方式,其实就是对URL发起增删改查的操作。
kubectl proxy --port=8888 & // 代理
curl http://localhost:8888/api/v1/namespaces/default
curl http://localhost:8888/apis/apps/v1/namespaces/default/deployments
以上两种api的区别是:
api
它是一个特殊链接,只有在核心v1群组中的对象才能使用。apis
它是一般API访问的入口固定格式名。
2 UserAccount 与 serviceaccount
- 用户账户是针对人而言的。 服务账户是针对运行在 pod 中的进程而言的。
- 用户账户是全局性的。 其名称在集群各 namespace 中都是全局唯一的,未来的用户资源不会做 namespace 隔离, 服务账户是namespace 隔离的。
- 通常情况下,集群的用户账户可能会从企业数据库进行同步,其创建需要特殊权限,并且涉及到复杂的业务流程。服务账户创建的目的是为了更轻量,允许集群用户为了具体的任务创建服务账户 ( 即权限最小化原则 )。
2.1 创建serviceaccount:
[kubeadm@server1 ~]$ kubectl create serviceaccount test
serviceaccount/test created
[kubeadm@server1 ~]$ kubectl get sa
NAME SECRETS AGE
default 1 19d
nfs-client-provisioner 1 3d7h
test 1 10s
[kubeadm@server1 ~]$ kubectl describe sa test //此时k8s为用户自动生成认证信息,但没有授权
Name: test
Namespace: default
Labels: <none>
Annotations: <none>
Image pull secrets: <none>
Mountable secrets: test-token-nxqrn
Tokens: test-token-nxqrn
Events: <none>
2.2 添加secrets到serviceaccount中
博客 中创建的kubernetes.io/dockerconfigjson
类型的sercets:myregistrykey
用于存储docker registry的认证信息
[kubeadm@server1 ~]$ kubectl patch serviceaccount test -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}'
serviceaccount/test patched
[kubeadm@server1 ~]$ kubectl describe sa test
Name: test
Namespace: default
Labels: <none>
Annotations: <none>
Image pull secrets: myregistrykey //可以读取拉取镜像的秘钥
Mountable secrets: test-token-nxqrn
Tokens: test-token-nxqrn
Events: <none>
2.3 把serviceaccount和pod绑定起来
让test对私有仓库进行认证
[kubeadm@server1 auth]$ cat pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: myapp
labels:
app: myapp
spec:
containers:
- name: myapp
image: reg.westos.org/westos/game2048
ports:
- name: http
containerPort: 80
serviceAccountName: test
将认证信息添加到serviceAccount中,要比直接在Pod指定imagePullSecrets要安全很多。
2.4 创建useraccount
[root@server2 pki]# cd /etc/kubernetes/pki/ // 证书的存放位置
[root@server2 pki]# ll . -d // 只允许超户写入
drwxr-xr-x 3 root r