linux--kubernetes(访问控制)

kubernetes API 访问控制

• 认证（任意一种） -->授权（一般是rbac 和 node）–> 准入控制（自己选择）

认证 Authentication

• 认证一共有8种，可以启动一种或多种认证方式，只要有一种认证方式通过，就不再对其它方式认证，通常启动X 509 Client Certs 和Service Accout Tokens两种认证方式
• k8s集群有两类用户： 由k8s管理的Service Accounts 服务帐号和 Users Accounts
  普通账户，k8s种的帐号是形式上存在的。

默认存在的taken

• 访问k8s的API Server的客户端主要分为两类：

  1.kubectl: 用户家目录种的.kube/config就保存了密钥相关信息，自动读取
  2.pod: pod中的进程需要访问API Server。如果是人去访问或编写的脚本去访问，这类访问的帐号为：UserAccount;pod自身访问时使用的帐号时ServerAccount,生产中后者使用居多。

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访问的入口固定格式名

创建ServerAccount

• 添加secret

• 让test对私有仓库进行认证

apiVersion: v1
kind: Pod
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  containers:
 - name: nginx
    image: reg.westos.org/westos/game2048
    ports:
    - name: http
      containerPort: 80
  serviceAccountName: test

• 创建pod,sa test对私有仓库有认证，所以可以下载镜像
• 方法是将认证信息添加到sa里面，比在pod中直接指定要安全的多

创建UserAccount

• 在超户下创建证书

cd /etc/kubernetes/pki/
openssl genrsa -out test.key 2048
openssl req -new -key test.key -out test.csr -subj "/CN=test"
openssl x509 -req -in test.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out test.crt -days 365
openssl x509 -in test.crt -text -noout

• 在kubeadm识别

kubectl config set-credentials test --client-certificate=/etc/kubernetes/pki/test.crt --client-key=/etc/kubernetes/pki/test.key --embed-certs=true    
识别
kubectl config set-context test@kubernetes --cluster=kubernetes --user=test  
创建
kubectl config use-context test@kubernetes
登陆           

没有权限

授权 Authorization

• 认证之后进行授权，根据所有授权策略匹配请求资源属性，决定允许或拒绝请求。授权方式有6种：
  AlwayAllow,ABAC,RBAC,Webhook,Node。级全默认开启RBAC.。

• RBAC：基于角色访问控制授权。

  • 允许管理员通过k8s API动态配置授权策略。RBACj就是用户通过角色与权限进行关联。
  • RBAC只有授权，没有拒绝授权，所以只需要定义允许该用户做什么即
  • RBAC包括四种类型：Role,ClusterRole,RoleBinding,ClusterRoleBinding

• RBAC的三个基本概念：

       - subject: 被作用者，user,group,sa
       - role:角色，其实是一种规则，定义了一组对k8s API对象的操作权限
       - rolebinding: 角色和被作用者的绑定关系
  

• role和clusterrole

            - role: 一系列权限的集合，只能对单个namespaces做出权限处理操作
            - clusterrole: 集群全局使用
  

注意切换回kubernetes-admin@kubernetes

[kubeadm@server2 auth]$ cat role.yaml 
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: myrole
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get","watch","list","create","update","patch","delete"]

• rolebinding和clusterrolebinding:

  • rolebinding:将role中定义的权限授予给用户或用户组。它包含一个subjects列（users,groups,service
    accounts）,引用该role

  • rolebinding: 对某个namespace内授权，clusterrolebinding射俑在集群范围内使用

[kubeadm@server2 auth]$ cat rolebinding.yaml 
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: test-read-pods
  namespace: default
subjects:
- kind: User
  name: test
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: myrole
  apiGroup: rbac.authorization.k8s.io

test只对pod有权限

上面的角色只针对default namespaces

针对集群

创建角色：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: myclusterrole
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get","watch","list","create","update","delete"]
- apiGroups: ["extensions","apps"]
  resources: ["deployments"]
  verbs: ["get","watch","list","create","update","patch","delete"]

创建绑定：

角色绑定

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: rolebind-myclusterrole
  namespace: default
subjects:
- kind: User
  name: test
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: myclusterrole
  apiGroup: rbac.authorization.k8s.io

[kubeadm@server2 auth]$ kubectl get clusterrole
kubectl get rolebindings.rbac.authorization.k8s.io
kubectl get clusterrolebindings.rbac.authorization.k8s.io
查看

只会有设定的权限

集群角色绑定

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: clusterrolebind-myclusterrole
subjects:
- kind: User
  name: test
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: myclusterrole
  apiGroup: rbac.authorization.k8s.io

因为没有设定特定的namespace
所以test对pod 和 deployments的所有namespaces都有权限

准入控制 Admission Control

• 用于拦截请求的一种方式，运行在认证，授权之后，是权限认证链上的最后一环，对请求API资源对象进行修改和校验

• 服务账户管理器管理各命名空间下的服务账户，并且保证每个活跃的命名空间下存在一个名为“default"的服务账户

• mynamespace中的所有sa

subjects:
 - kind: Group
  name: system:serviceaccounts:mynamespace
  apiGroup: rbac.authorization.k8s.io

• 整个系统中的所有sa

subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroup: rbac.authorization.k8s.io

kubernetes提供了4各预先定义好的clusterrole来供用户直接使用

• cluster-admin
• admin
• edit
• view

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: readonly-default
subjects:
- kind: ServiceAccount
  name: default
  namespace: defult
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io