个人博客
k8s 对我们整个系统的认证，授权，访问控制做了精密的设置；对于 k8s 集群来说，apiserver 是整 个集群访问控制的唯一入口，我们在 k8s 集群之上部署应用程序的时候，也可以通过宿主机的 NodePort 暴露的端口访问里面的程序，用户访问 kubernetes 集群需要经历如下认证过程：认证 ->授权->准入控制（adminationcontroller）
1.认证(Authenticating)是对客户端的认证，通俗点就是用户名密码验证
2.授权(Authorization)是对资源的授权，k8s 中的资源无非是容器，最终其实就是容器的计算，网 络，存储资源，当一个请求经过认证后，需要访问某一个资源（比如创建一个 pod），授权检查会根 据授权规则判定该资源（比如某 namespace 下的 pod）是否是该客户可访问的。
3.准入控制器（Admission Controller）位于 API Server 中，在对象被持久化之前，准入控制器拦 截对 API Server 的请求，一般用来做身份验证和授权。其中包含webhook两个特殊的控制器：
变更（Mutating）准入控制：修改请求的对象
验证（Validating）准入控制：验证请求的对
准入控制器是在 API Server 的启动参数配置的。一个准入控制器可能属于以上两者中的一种，也 可能两者都属于。当请求到达 API Server 的时候首先执行变更准入控制，然后再执行验证准入控 制。
k8s 的整体架构也是一个微服务的架构，所有的请求都是通过一个 GateWay，也就是 kubeapiserver 这个组件（对外提供 REST 服务），k8s 中客户端有两类，一种是普通用户，一种是集群 内的 Pod，这两种客户端的认证机制略有不同，但无论是哪一种，都需要依次经过认证，授权，准 入这三个机制。
Kubernetes 的授权是基于插件形成的，其常用的授权插件有以下几种：
1）Node（节点认证）
2）ABAC(基于属性的访问控制)
3）RBAC（基于角色的访问控制）***
4）Webhook（基于 http 回调机制的访问控制）
什么是RBAC
让一个用户（Users）扮演一个角色（Role），角色拥有权限，从而让用户拥有这样的权限，随后在 授权机制当中，只需要将权限授予某个角色，此时用户将获取对应角色的权限，从而实现角色的访问 控制。
在 k8s 的授权机制当中，采用 RBAC 的方式进行授权，其工作逻辑是，把对对象的操作权限定义到 一个角色当中，再将用户绑定到该角色，从而使用户得到对应角色的权限。如果通过 rolebinding 绑定 role，只能对 rolebingding 所在的名称空间的资源有权限，上图 user1 这个用户绑定到 role1 上，只对 role1 这个名称空间的资源有权限，对其他名称空间资源没有权限，属于名称空间级 别的；
另外，k8s 为此还有一种集群级别的授权机制，就是定义一个集群角色（ClusterRole），对集群内 的所有资源都有可操作的权限，从而将 User2 通过 ClusterRoleBinding 到 ClusterRole，从而使 User2 拥有集群的操作权限。
1.用户通过 rolebinding 绑定 role
2.用户通过 clusterrolebinding 绑定 clusterrole
3.用户通过rolebinding 绑定 clusterrole:
假如有 6 个名称空间，每个名称空间的用户都需要对自己的名称空间有管理员权限，那么需要定义 6 个 role 和 rolebinding，然后依次绑定，如果名称空间更多，我们需要定义更多的 role，这个是很 麻烦的，所以我们引入 clusterrole，定义一个 clusterrole，对 clusterrole 授予所有权限，然后用 户通过 rolebinding 绑定到 clusterrole，就会拥有自己名称空间的管理员权限了 注：RoleBinding 仅仅对当前名称空间有对应的权限。
kubernetes 中账户区分为：User Accounts（用户账户） 和 Service Accounts（服务账户） 两种：
UserAccount 是给 kubernetes 集群外部用户使用的，例如运维或者集群管理人员，，kubeadm 安装的 k8s，默认用户账号是 kubernetes-admin；
k8s 客户端(一般用:kubectl) ------>API Server
APIServer 需要对客户端做认证，使用 kubeadm 安装的 K8s，会在用户家目录下创建一个认 证配置文件 .kube/config 这里面保存了客户端访问 API Server 的密钥相关信息，这样当用 kubectl 访问 k8s 时，它就会自动读取该配置文件，向 API Server 发起认证，然后完成操作请求。#默认cd ~/.kube/config
ServiceAccount 是 Pod 使用的账号，Pod 容器的进程需要访问 API Server 时用的就是 ServiceAccount 账户；ServiceAccount 仅局限它所在的 namespace，每个 namespace 创建时都会 自动创建一个 default service account；创建 Pod 时，如果没有指定 Service Account，Pod 则会使 用 default Service Account。
RBAC 介绍
在 Kubernetes 中，所有资源对象都是通过 API 进行操作，他们保存在 etcd 里。而对 etcd 的操作 我们需要通过访问 kube-apiserver 来实现，上面的 Service Account 其实就是 APIServer 的认证过 程，而授权的机制是通过 RBAC：基于角色的访问控制实现。
Role 总是用来在某个名字空间内设置访问权限； 在你创建 Role 时，你必须指定该 Role 所属的名字空间。
ClusterRole 则是一个集群作用域的资源。这两种资源的名字不同（Role 和 ClusterRole） 是因为 Kubernetes 对象要么是名字空间作用域的，要么是集群作用域的，不可两者兼具。
如果你希望在名字空间内定义角色，应该使用 Role； 如果你希望定义集群范围的角色，应该使用 ClusterRole。
作用于命令空间的权限
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""] # "" 标明 core API 组
resources: ["pods"]
verbs: ["get", "watch", "list"]
ClusterRole可以用于授予Role的权限，也可以用于：
集群范围资源（比如节点（Node））
非资源端点（比如
/healthz）[root@master2 secret]# curl https://localhost:6443/healthz -k
ok跨名字空间访问的名字空间作用域的资源（如 Pod）
比如，你可以使用 ClusterRole 来允许某特定用户执行
kubectl get pods --all-namespaces
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
# "namespace" 被忽略，因为 ClusterRoles 不受名字空间限制
name: secret-reader
rules:
- apiGroups: [""]
# 在 HTTP 层面，用来访问 Secret 资源的名称为 "secrets"
resources: ["secrets"]
verbs: ["get", "watch", "list"]
角色绑定（Role Binding）是将角色中定义的权限赋予一个或者一组用户。 它包含若干 主体（用户、组或服务账户）的列表和对这些主体所获得的角色的引用。
RoleBinding 在指定的名字空间中执行授权，而 ClusterRoleBinding 在集群范围执行授权。
下面的例子中的 RoleBinding 将 “pod-reader” Role 授予在 “default” 名字空间中的用户 “jane”。 这样，用户 “jane” 就具有了读取 “default” 名字空间中所有 Pod 的权限。
apiVersion: rbac.authorization.k8s.io/v1
# 此角色绑定允许 "jane" 读取 "default" 名字空间中的 Pod
# 你需要在该命名空间中有一个名为 “pod-reader” 的 Role
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
# 你可以指定不止一个“subject（主体）”
- kind: User
name: jane # "name" 是区分大小写的
apiGroup: rbac.authorization.k8s.io
roleRef:
# "roleRef" 指定与某 Role 或 ClusterRole 的绑定关系
kind: Role # 此字段必须是 Role 或 ClusterRole
name: pod-reader # 此字段必须与你要绑定的 Role 或 ClusterRole 的名称匹配
apiGroup: rbac.authorization.k8s.io
RoleBinding 也可以引用 ClusterRole，以将对应 ClusterRole 中定义的访问权限授予 RoleBinding 所在名字空间的资源。这种引用使得你可以跨整个集群定义一组通用的角色， 之后在多个名字空间中复用。
例如，尽管下面的 RoleBinding 引用的是一个 ClusterRole，“dave”（这里的主体， 区分大小写）只能访问 “development” 名字空间中的 Secrets 对象，因为 RoleBinding 所在的名字空间（由其 metadata 决定）是 “development”。
apiVersion: rbac.authorization.k8s.io/v1
# 此角色绑定使得用户 "dave" 能够读取 "development" 名字空间中的 Secrets
# 你需要一个名为 "secret-reader" 的 ClusterRole
kind: RoleBinding
metadata:
name: read-secrets
# RoleBinding 的名字空间决定了访问权限的授予范围。
# 这里隐含授权仅在 "development" 名字空间内的访问权限。
namespace: development
subjects:
- kind: User
name: dave # 'name' 是区分大小写的
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io
集群角色绑定的角色只能是集群角色，用于进行集群级别或对所有命名空间都生效的授权
apiVersion: rabc.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: read-secret-global
subjects:
- kind: Group
name: manager
apiGroup: rabc.authorization.k8s.io
ruleRef:
- kind: ClusterRole
name: secret-read
apiGroup: rabc.authorization.k8s.io
多数资源可以用其名称的字符串表示，也就是 Endpoint 中的 URL 相对路径，例如 pod 中的日志是 GET /api/v1/namaspaces/{namespace}/pods/{podname}/log 如果需要在一个 RBAC 对象中体现上下级资源，就需要使用“/”分割资源和下级资源。
例如：若想授权让某个主体同时能够读取 Pod 和 Pod log，则可以配置 resources 为一个数组
apiVersion: rabc.authorization.k8s.io/v1
kind: Role
metadata:
name: logs-reader
namespace: default
rules:
- apiGroups: [""]
resources: ["pods","pods/log"]
verbs: ["get","list"]
资源还可以通过名称（ResourceName）进行引用，在指定 ResourceName 后，使用 get、 delete、update、patch 请求，就会被限制在这个资源实例范围内
例如，下面的声明让一个主体只能对名为 my-configmap 的 Configmap 进行 get 和 update 操 作：
apiVersion: rabc.authorization.k8s.io/v1
kind: Role
metadata:
namaspace: default
name: configmap-update
rules:
- apiGroups: [""]
resources: ["configmap"]
resourceNames: ["my-configmap"]
verbs: ["get","update"]
（1）允许读取核心 API 组的 Pod 资源
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get","list","watch"]
（2）允许读写 extensions 和 apps 两个 API 组中的 deployment 资源
rules:
- apiGroups: ["extensions","apps"]
resources: ["deployments"]
verbs: ["get","list","watch","create","update","patch","delete"
（3）允许读取 Pod 以及读写 job 信息
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get","list","watch"]、
- apiVersion: ["batch","extensions"]
resources: ["jobs"]
verbs: ["get","list","watch","create","update","patch","delete"]
（4）允许读取一个名为 my-config 的 ConfigMap（必须绑定到一个 RoleBinding 来限制到一个 Namespace 下的 ConfigMap）：
rules:
- apiGroups: [""]
resources: ["configmap"]
resourceNames: ["my-configmap"]
verbs: ["get"]
（5）读取核心组的 Node 资源（Node 属于集群级的资源，所以必须存在于 ClusterRole 中，并使 用 ClusterRoleBinding 进行绑定）：
rules:
- apiGroups: [""]
resources: ["nodes"]
verbs: ["get","list","watch"]
（6）允许对非资源端点“/healthz”及其所有子路径进行 GET 和 POST 操作（必须使用 ClusterRole 和 ClusterRoleBinding）：
rules:
- nonResourceURLs: ["/healthz","/healthz/*"]
verbs: ["get","post"]
（1）用户名 alice
subjects:
- kind: User
name: alice
apiGroup: rbac.authorization.k8s.io
（2）组名 alice
subjects:
- kind: Group
name: alice
apiGroup: rbac.authorization.k8s.io
（3）kube-system 命名空间中默认 Service Account
subjects:
- kind: ServiceAccount
name: default
namespace: kube-system
（4）qa 命名空间中的所有 Service Account：
subjects:
- kind: Group
name: system:serviceaccounts:qa
apiGroup: rbac.authorization.k8s.io
（5）所有 Service Account
subjects:
- kind: Group
name: system:serviceaccounts
apiGroup: rbac.authorization.k8s.io
（6）所有认证用户
subjects:
- kind: Group
name: system:authenticated
apiGroup: rbac.authorization.k8s.io
（7）所有未认证用户
subjects:
- kind: Group
name: system:unauthenticated
apiGroup: rbac.authorization.k8s.io
（8）全部用户
subjects:
- kind: Group
name: system:authenticated
apiGroup: rbac.authorization.k8s.io
- kind: Group
name: system:unauthenticated
apiGroup: rbac.authorization.k8s.io
Service Account 也是一种账号，是给运行在 Pod 里的进程提供了必要的身份证明。需要在 Pod 定义中指明引用的 Service Account，这样就可以对 Pod 的进行赋权操作。例如：pod 内可获取 rbac 命名空间的所有 Pod 资源，pod-reader-sc 的 Service Account 是绑定了名为 pod-read 的 Role:
apiVersion: v1
kind: Pod
metadata:
name: nginx
namespace: rbac
spec:
serviceAccountName: pod-reader-sc
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
默认的 RBAC 策略为控制平台组件、节点和控制器授予有限范围的权限，但是除 kube-system 外 的 Service Account 是没有任何权限的。
#（1）为一个应用专属的 Service Account 赋权此应用需要在 Pod 的 spec 中指定一个 serviceAccountName，用于 API、Application Manifest、kubectl create serviceaccount 等创建 Service Account 的命令。
#例如为 my-namespace 中的 my-sa Service Account 授予只读权限
kubectl create rolebinding my-sa-view --clusterrole=view --serviceaccount=mynamespace:my-sa --namespace=my-namespace
#（2）为一个命名空间中名为 default 的 Service Account 授权如果一个应用没有指定 serviceAccountName，则会使用名为 default 的 Service Account。注意，赋予 Service Account “default”的权限会让所有没有指定 serviceAccountName 的 Pod都具有这些权限
#例如，在 my-namespace 命名空间中为 Service Account“default”授予只读权限：
kubectl create rolebinding default-view --clusterrole=view --serviceaccount=mynamespace:default --namespace=my-namespace
#另外，许多系统级 Add-Ons 都需要在 kube-system 命名空间中运行，要让这些 Add-Ons 能够使用超级用户权限，则可以把 cluster-admin 权限赋予 kube-system 命名空间中名为 default 的Service Account，这一操作意味着 kube-system 命名空间包含了通向 API 超级用户的捷径。
kubectl create clusterrolebinding add-ons-add-admin --clusterrole=cluster-admin --serviceaccount=kube-system:default
#（3）为命名空间中所有 Service Account 都授予一个角色如果希望在一个命名空间中，任何 Service Account 应用都具有一个角色，则可以为这一命名空间的 Service Account 群组进行授权
kubectl create rolebinding serviceaccounts-view --clusterrole=view --group=system:serviceaccounts:my-namespace --namespace=my-namespace
#（4）为集群范围内所有 Service Account 都授予一个低权限角色如果不想为每个命名空间管理授权，则可以把一个集群级别的角色赋给所有 Service Account。
kubectl create clusterrolebinding serviceaccounts-view --clusterrole=view --group=system:serviceaccounts
#（5）为所有 Service Account 授予超级用户权限
kubectl create clusterrolebinding serviceaccounts-view --clusterrole=cluster-admin --group=system:serviceaccounts
#（1）在命名空间 rbac 中为用户 es 授权 admin ClusterRole：
kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=es --namespace=rbac
#（2）在命名空间 rbac 中为名为 myapp 的 Service Account 授予 view ClusterRole：
kubctl create rolebinding myapp-role-binding --clusterrole=view --serviceaccount=rbac:myapp --namespace=rbac
#（3）在全集群范围内为用户 root 授予 cluster-admin ClusterRole：
kubectl create clusterrolebinding cluster-binding --clusterrole=cluster-admin --user=root
#（4）在全集群范围内为名为 myapp 的 Service Account 授予 view ClusterRole：
kubectl create clusterrolebinding service-account-binding --clusterrole=view --serviceaccount=myapp
yaml 文件进行 rbac 授权：https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/
#（1）生成一个私钥
cd /etc/kubernetes/pki/
(umask 077; openssl genrsa -out lucky.key 2048)
#（2）生成一个证书请求
openssl req -new -key lucky.key -out lucky.csr -subj "/CN=lucky"
#（3）生成一个证书
openssl x509 -req -in lucky.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out lucky.crt -days 3650
#在 kubeconfig 下新增加一个 lucky 这个用户
#（1）把 lucky 这个用户添加到 kubernetes 集群中，可以用来认证 apiserver 的连接
kubectl config set-credentials lucky --clientcertificate=./lucky.crt --client-key=./lucky.key --embed-certs=true
#（2）在 kubeconfig 下新增加一个 lucky 这个账号
kubectl config set-context lucky@kubernetes --cluster=kubernetes --user=lucky
#（3）切换账号到 lucky，默认没有任何权限
kubectl config use-context lucky@kubernetes
kubectl config use-context kubernetes-admin@kubernetes #这个是集群用户，有任何权限
#把 user 这个用户通过 rolebinding 绑定到 clusterrole 上，授予权限,权限只是在 lucky 这个名称空间有效
#（1）把 lucky 这个用户通过 rolebinding 绑定到 clusterrole 上
kubectl create ns lucky
kubectl create rolebinding lucky -n lucky --clusterrole=cluster-admin --user=lucky
#（2）切换到 lucky 这个用户
kubectl config use-context lucky@kubernetes
#（3）测试是否有权限
kubectl get pods -n lucky
#有权限操作这个名称空间
kubectl get pods
#没有权限操作其他名称空间
#添加一个 lucky 的普通用户
useradd lucky
cp -ar /root/.kube/ /home/lucky/
chown -R lucky.lucky /home/lucky/
su - lucky
kubectl get pods -n lucky