【クラウドネイティブ｜Kubernetesをゼロから学ぶ】第28回、記事終了～rbac認可徹底解説

この記事は「k8s をゼロから学ぶ」というコラムに含まれています。前回
の記事: Configuration Management Center のシークレットと rbac の承認クリックジャンプ

前の記事の次の部分

1、サービスアカウント

サービス アカウントは、Pod で Kubernetes API やその他の外部サービスを呼び出すプロセスを容易にするように設計されています。ユーザー アカウントとは異なります. ユーザー アカウントは人々のために設計されています. サービス アカウントは Pod 内のプロセスが Kubernetes API を呼び出すために設計されています. ユーザー アカウントは複数の名前空間にまたがっています.名前空間は、デフォルトのサービス アカウントを自動的に作成します。ServiceAccount アドミッション コントローラーを開くと、

1) 各 Pod は、作成後に自動的に spec.serviceAccount をデフォルトに設定します (別の ServiceAccout が指定されていない場合)。

2) Pod が参照するサービス アカウントが既に存在することを確認します。存在しない場合は作成を拒否します。

Pod の作成時に serviceaccount が指定されていない場合、システムは Pod と同じ名前空間にあるデフォルトのサービス アカウントを自動的に割り当てます。これは、次のように、ポッドと apiserver 間の通信用のアカウントです。

[root@k8smaster secret]# kubectl get pods
NAME                               READY   STATUS              RESTARTS   AGE
mysql-pod-volume                   1/1     Running             0          50m
nginx-f89759699-5qdtn              1/1     Running             1          19d
pod-secret                         1/1     Running             0          17m
pod-secret-volume                  1/1     Running             0          11m
[root@k8smaster secret]# kubectl get pods mysql-pod-volume -o yaml | grep "serviceAccountName"
  serviceAccountName: default
[root@k8smaster secret]# kubectl describe pods mysql-pod-volume
Volumes:
  mysql-config:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      mysql
    Optional:  false
  default-token-788ff:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-788ff
    Optional:    false

 
从上面可以看到每个 Pod 无论定义与否都会有个存储卷，这个存储卷为 default-token-***。pod 和 apiserver 的认证信息通过 secret 进行定义，由于认证信息属于敏感信息，所以需要保存在 secret 资源当中，并以存储卷的方式挂载到 Pod 当中。从而让 Pod 内运行的应用通过对应的 secret 中的信息来连接 apiserver，并完成认证。每个 namespace 中都有一个默认的叫做 default 的 serviceaccount 资源。查看名称空间内的 secret，也可以看到对应的 default-token。让当前名称空间中所有的 pod 在连接 apiserver 时可以使用的预制认证信息，从而保证 pod 之间的通信。
 
[root@k8smaster secret]# kubectl get sa
NAME              SECRETS   AGE
default           1         19d

[root@k8smaster secret]# kubectl get secret
NAME                          TYPE                                  DATA   AGE
default-token-788ff           kubernetes.io/service-account-token   3      19d

默认的 service account 仅仅只能获取当前 Pod 自身的相关属性，无法观察到其他名称空间 Pod 的相关属性信息。如果想要扩展 Pod，假设有一个 Pod 需要用于管理其他 Pod 或者是其他资源对象，是无法通过自身的名称空间的 serviceaccount 进行获取其他 Pod 的相关属性信息的，此时就需要进行手动创建一个 serviceaccount，并在创建 Pod 时进行定义。那么 serviceaccount 该如何进行定义呢？实际上，service accout 也属于一个 k8s 资源，serviceAccount 也属于标准的 k8s 资源，可以创建一个 serviceAccount，创建之后由我们创建的 pod 使用 serviceAccountName 去加载自己定义的 serviceAccount 就可以了，如下：

[root@k8smaster secret]# kubectl create sa paopao
serviceaccount/paopao created
[root@k8smaster secret]# kubectl get sa
NAME              SECRETS   AGE
default           1         19d
nfs-provisioner   1         47h
paopao            1         3s
[root@k8smaster secret]# kubectl describe sa paopao
Name:                paopao
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   paopao-token-g72jh
Tokens:              paopao-token-g72jh			#自动生成token
Events:              <none>
[root@k8smaster secret]# kubectl get secret
NAME                          TYPE                                  DATA   AGE
default-token-788ff           kubernetes.io/service-account-token   3      19d
mysecret                      Opaque                                2      27m
mysql-password                Opaque                                1      40m
nfs-provisioner-token-tv5dl   kubernetes.io/service-account-token   3      2d
paopao-token-g72jh            kubernetes.io/service-account-token   3      31s		#自动生成secret
[root@k8smaster secret]# kubectl describe secret paopao-token-g72jh 
Name:         paopao-token-g72jh
Namespace:    default
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: paopao
              kubernetes.io/service-account.uid: 74643ebf-6198-4b3a-9aee-ea0da0e6b1a8

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1025 bytes
namespace:  7 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6ImpCVzZXa0U2WDczX0NMeU1yUDM5YkluTWVPdlNFbUp0UnF3aVNnVzhXTkUifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InBhb3Bhby10b2tlbi1nNzJqaCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJwYW9wYW8iLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiI3NDY0M2ViZi02MTk4LTRiM2EtOWFlZS1lYTBkYTBlNmIxYTgiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6ZGVmYXVsdDpwYW9wYW8ifQ.IzS3gXVOMXlKWSyVk-4Xh04351XkoG5axWba1fOwhrFLMNRT2RdMm3LRvvki_WIuL8prvGNerMt4cG3YzRIgLMTZ1Rk3BtLzo3HY9D4qr4FxZxXdFsqd87kHG5_ExpqzAHn__anL5758XMvsuQCwf-k6wRktbGOIDb6jXZuCVViRyomWWPJaLIBXa5BBlXHKft9mXuM6--293w21-RPTW29tMaIVf18bWXU3OpaPFiULtpUB3faqqmS3H7dKrbwn1uhSwmp4mxU1ossXCcPAdxL-Shh9L3yZ6fTuZTDxgmKb9yF6twVwcmuLr5HFZ3a5Tr_TVI91Z6IBXYlnu0bYuw	#可以看到有这个

上面可以看到生成了 paopao-token-g72jh 的 token 详细信息，这个 token 就是 sa 连接 apiserver 的认证信息，这个 token 也是登陆 k8s dashboard 的 token，这些是一个认证信息，能够登陆k8s，能认证到 k8s，但是不能做别的事情，不代表权限，想要做其他事情，需要授权
#比如在pod部署一个prometheus,如果要获取k8s监控指标要和apiserver交互，不然无法获取，这个时候需要生成sa，做一个rbac授权，比如可以对k8s所有资源下的所有名称空间都访问，才能获取到k8s资源

2. kubeconfig ファイル

K8S クラスターでは、リソースへの各ユーザーのアクセスには、apiserver を介した通信認証が必要です. このメカニズムでは、リソースへのアクセスは、トークンまたは構成ファイルを介して行うことができます. 認証情報を使用して、kubectl config を介して構成を表示できます。次のとおりです。

[root@k8smaster secret]# kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://192.168.11.139:6443	#apiserver 的地址
  name: kubernetes						#集群的名字
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes		#上下文的名字
current-context: kubernetes-admin@kubernetes	#当前上下文的名字
kind: Config
preferences: {
    
    }
users:
- name: kubernetes-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
在上面的配置文件当中，定义了集群、上下文以及用户。其中 Config 也是 K8S 的标准资源之一，在该配置文件当中定义了一个集群列表，指定的集群可以有多个；用户列表也可以有多个，指明集群。而在上下文列表当中，是进行定义可以使用哪个用户对哪个集群进行访问，以及当前使用的上下文是什么。

承認する

ユーザーが認証に合格した場合、そのユーザーには権限がなく、リソースの追加や削除など、追加の承認操作が必要になります。 kubernetes 1.6 以降では、RBAC (Role-based Access Control Mechanism) 承認チェック メカニズムがあります。 . Kubernetes の認可は、プラグインに基づいて形成されます。一般的に使用される認可プラグインは次のとおりです。

１）ノード（ノード認証）

2) ABAC (属性ベースのアクセス制御)

3) RBAC (ロールベースのアクセス制御)

4) Webhook (httpコールバック機構によるアクセス制御)

RBAC (役割ベースのアクセス制御) とは何ですか?

ユーザー (ユーザー) にロール (ロール) を演じさせ、ロールにはパーミッションがあるため、ユーザーはそのようなパーミッションを持ち、認証メカニズムではロールにパーミッションを付与するだけでよく、ユーザーは対応するパーミッションを取得します。ロール。これにより、ロールのアクセス制御が有効になります。図に示すように:

k8sの認可メカニズムでは、認可にRBACを使用しており、オブジェクトの操作権限をロールに定義し、ユーザーをロールにバインドすることで、ユーザーは対応するロールの権限を取得できるようになっています。 . rolebinding でロールをバインドすると、rolebingding が配置されている名前空間のリソースに対してのみアクセス許可を持つことができます. 上の図では、ユーザー user1 は role1 にバインドされており、role1 名前空間のリソースに対してのみアクセス許可を持っていますが、他の名前空間リソースではなく、名前空間レベルに属します。

さらに、k8s には、この目的のためのクラスター レベルの承認メカニズムもあります。これは、クラスター内のすべてのリソースに対する操作権限を持つクラスター ロール (ClusterRole) を定義することで、User2 が ClusterRoleBinding を ClusterRole に渡すことができるようにします。 User2 がクラスタの権限を持っていること 操作権限。

Role、RoleBinding、ClusterRole、ClusterRoleBinding の関係は次のとおりです。

上の図からわかるように、ロールは rolebinding でバインドでき、clusterrole は rolebinding でバインドでき、clusterrole は clusterrolebinding でバインドできます。

上記では、2 つのロール バインディングについて説明しました。

(1) ユーザーはロールバインディングを介してロールをバインドします

(2) ユーザーは clusterrolebinding を介して clusterrole をバインドします

別のものがあります: rolebinding binding clusterrole

クラスターロールをバインドする役割結合の利点:
6 つの名前空間があり、各名前空間のユーザーが自分の名前空間に対する管理者権限を持っている必要がある場合、6 つの役割と役割結合を定義してから、名前空間がより多くの場合、順番にバインドする必要があります。 、より多くのロールを定義する必要があり、これは非常に面倒なので、clusterrole を導入し、clusterrole を定義し、clusterrole にすべての権限を付与します。その後、ユーザーは rolebinding を介して clusterrole にバインドし、自分の名前空間の管理者権限を持ちます。スパン

注: RoleBinding には、現在の名前空間に対応する権限しかありません。

アドミッションコントロール

一般的に言えば, アドミッションコントロールは, 認可チェックが完了した後に他の後続のセキュリティチェック操作を定義するためにのみ使用されます. 認可メカニズムをさらに補完し, 複数のプラグインの組み合わせによって実装されます. 一般的に言えば, 作成するために使用されます, 削除する、変更または代理として行動する. 随時補足.

Kubernetes のアドミッション コントロールは、実際にはアドミッション コントローラ プラグインのリストです. APIServer に送信されたリクエストは、このリスト内の各アドミッション コントローラ プラグインによってチェックされる必要があります. 特定のコントローラ プラグインがアドミッションに失敗すると、アクセスは失敗します.

コントローラープラグインは次のとおりです。

AlwaysAdmit: すべてのリクエストを許可する

AlwaysPullImages: コンテナーを開始する前に常にイメージをダウンロードします。これは、コンテナーが開始されるたびにコンテナー イメージの使用が承認されているかどうかを確認することと同じです。

AlwaysDeny: テストのために、すべてのリクエストの通過を禁止します

DenyEscalatingExec: exec へのエンドユーザー アクセスを拒否し、エスカレートされた権限でポッドにコマンドをアタッチします。このプラグインは、昇格された権限を含むコンテナーを一元化し、それらのコンテナーでエンド ユーザーがコマンドを実行する機能を制限したい場合に推奨されます。

ImagePolicyWebhook ServiceAccount: このプラグインは、serviceAccounts などの自動化を実装します。ServiceAccount オブジェクトを使用する場合は、このプラグインを使用することを強くお勧めします

SecurityContextDeny: Pod 定義で定義されたすべての SecurityContext オプションを無効にします。

SecurityContext には、コンテナー内の fsGroup、selinux などの OS レベルのセキュリティ オプションを定義するオプションが含まれています。

ResourceQuota: 名前空間のクォータ管理に使用され、受信リクエストを監視して、名前空間のクォータを超えないようにします。このプラグインは、アドミッション コントローラ リストの最後に配置することをお勧めします。ResourceQuota アドミッション コントローラーは、名前空間で作成されるリソースの数を制限できるだけでなく、名前空間で Pod によって要求されるリソースの合計量も制限できます。ResourceQuota アドミッション コントローラーと ResourceQuota リソース オブジェクトは連携して、リソース クォータ管理を実装します。

LimitRanger: Pod とコンテナーのクォータ管理のために、受信リクエストを監視して、Pod とコンテナーのクォータを超えないようにします。アドミッション コントローラ LimitRange とリソース オブジェクト LimitRange は、リソース制限管理を一緒に実装します。

NamespaceLifecycle: 存在しない名前空間でリソース オブジェクトを作成する要求があった場合、その要求は拒否されます。名前空間を削除すると、その名前空間にあるすべてのリソース オブジェクトが削除されます

DefaultStorageClass
DefaultTolerationSeconds
PodSecurityPolicy
当 Kubernetes 版本>=1.6.0，官方建议使用这些插件：
–admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds
当 Kubernetes 版本>=1.4.0，官方建议使用这些插件：
–admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota
以上是标准的准入插件，如果是自己定制的话，k8s1.7版 出了两个 alpha features, Initializers 和 External Admission Webhooks

RBAC 認証および認可ポリシー

RBAC の概要

Kubernetes では、すべてのリソース オブジェクトは API を介して操作され、etcd に格納されます。etcd の操作は kube-apiserver にアクセスすることで実現する必要があります. 上記の Service Account は実際には APIServer の認証プロセスであり、認可メカニズムは RBAC: role-based access control によって実現されます.

RBAC には、Role、ClusterRole、RoleBinding、および ClusterRoleBinding という 4 つのリソース オブジェクトがあります。

役割: 役割

一组权限的集合，在一个命名空间中，可以用其来定义一个角色，只能对命名空间内的资源进行授权。如果是集群级别的资源，则需要使用 ClusterRole。
例如：定义一个角色用来读取 Pod 的权限
apiVersion: rbac.authorization.k8s.io/v1		#认证相关的api
kind: Role
metadata:
  namespace: rbac 								#只能对rbac这个名称空间才有权限
  name: pod-read								
rules:											#策略
  - apiGroups: [""]								#k8s所有的apiversion都支持 kubectl api-versions查看
    resources: ["pods"] 						#资源名字
    resourceNames: []							#如果需要具体的pod就写具体的 不写就是所有的
    verbs: ["get","watch","list"]				#具体的步骤吗，获取，查看，以列表列出来
rules 中的参数说明：
1、apiGroups：支持的 API 组列表，例如："apiVersion: batch/v1"等
2、resources：支持的资源对象列表，例如 pods、deplayments、jobs 等
3、resourceNames: 指定 resource 的名称
4、verbs：对资源对象的操作方法列表。

ClusterRole: クラスターの役割

具有和角色一致的命名空间资源的管理能力，还可用于以下特殊元素的授权
1、集群范围的资源，例如 Node
2、非资源型的路径，例如：/healthz
3、包含全部命名空间的资源，例如 Pods
例如：定义一个集群角色可让用户访问任意 secrets
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secrets-clusterrole
rules:
  - apiGroups: [""]
    resources: ["secrets"]			#对所有名称空间下的secrets都有查看的权限
    verbs: ["get","watch","list"]

RoleBinding: ロール バインディング、ClusterRolebinding: クラスター ロール バインディング

角色绑定和集群角色绑定用于把一个角色绑定在一个目标上，可以是 User，Group，Service Account，使用 RoleBinding 为某个命名空间授权，使用 ClusterRoleBinding 为集群范围内授权。
例如：将在 rbac 命名空间中把 pod-read 角色授予用户 es
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-read-bind
  namespace: rbac
subjects:									#主体
- kind: User							
  name: es									#要对es这个用户
  apiGroup: rbac.authorization.k8s.io
roleRef:									#通过 pod-read-bind 绑定到roleref上
- kind: Role
  name: pod-read							#角色名字
  apiGroup: rbac.authorizatioin.k8s.io
#用户es在rbac这个命名空间下具有role设置的权限，比如资源查看

RoleBinding 也可以引用 ClusterRole，对属于同一命名空间内的 ClusterRole 定义的资源主体进行授权， 例如：es 能获取到集群中所有的资源信息
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: es-allresource
  namespace: rbac
subjects:
- kind: User
  name: es								#通过RoleBinding绑定到cluster-admin这个ClusterRole上 管理员的角色
  apiGroup: rbac.authorization.k8s.io
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin

集群角色绑定的角色只能是集群角色，用于进行集群级别或对所有命名空间都生效的授权
例如：允许 manager 组的用户读取所有 namaspace 的 secrets
apiVersion: rabc.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secret-global
subjects:
- kind: Group
  name: manager							#通过ClusterRoleBinding绑定到secret-read这个ClusterRole
  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: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: logs-reader
  namespace: default
rules:
- apiGroups: [""]
  resources: ["pods","pods/log"]				#对pods和podslog下的资源可以读取
  verbs: ["get","list"]

资源还可以通过名称（ResourceName）进行引用，在指定 ResourceName 后，使用 get、delete、update、patch 请求，就会被限制在这个资源实例范围内
例如，下面的声明让一个主体只能对名为 my-configmap 的 Configmap 进行 get 和 update 操作：
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namaspace: default
  name: configmap-update
rules:
- apiGroups: [""]
  resources: ["configmap"]
  resourceNames: ["my-configmap"]				#只能对这个名字my-configmap进行get和更新操作
  verbs: ["get","update"]

一般的な役割の例

(1) コア API グループの Pod リソースを読み取ることができます

rules:
- apiGroups: [""]					#读取所有apiversion的pods的资源可以查看信息等
  resources: ["pods"]
  verbs: ["get","list","watch"]

(2) 拡張機能およびアプリ API グループのデプロイ リソース ルールの読み取りと書き込みを許可します。

- apiGroups: ["extensions","apps"]									#组名，apiversion下也能看到组
  resources: ["deployments"]										#对上面两个组下的deplo资源有下面的权限
  verbs: ["get","list","watch","create","update","patch","delete"]  #查看 更新 删除等

(3) Podの読み込みとジョブ情報の読み書きを許可する

rules:
- apiGroups: [""]														#所有核心api
  resources: ["pods"]													#读取pods资源
  verbs: ["get","list","watch"]、
- apiVersion: ["batch","extensions"]									#能对这两个组的jobs资源删除更新等
  resources: ["jobs"]	
  verbs: ["get","list","watch","create","update","patch","delete"]

(4) my-config という名前の ConfigMap の読み取りを許可します (名前空間の下の ConfigMap に制限するには、RoleBinding にバインドする必要があります)。

rules:
- apiGroups: [""]					#所有api
  resources: ["configmap"]			#获取configmap资源
  resourceNames: ["my-configmap"]	#为资源取得名字，configmap可能很多，只能查看my-configmap这个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			#qa名称空间下所有的sa资源
  apiGroup: rbac.authorization.k8s.io

（5）所有 Service Account
subjects:
- kind: Group
  name: system:serviceaccounts				#所有的sa
  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

サービス アカウントの認可管理

サービス アカウントもアカウントであり、Pod で実行されているプロセスに必要な ID 証明を提供します。Pod に権限を付与できるように、参照されるサービス アカウントを Pod 定義で指定する必要があります。たとえば、rbac 名前空間のすべての Pod リソースは Pod で取得でき、pod-reader-sc のサービス アカウントは pod-read という名前の Role にバインドされます。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: rbac
spec:
  serviceAccountName: pod-reader-sc		#指定的sc 绑定到rbac命名空间下 可以读取pods
  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=my-namespace:my-sa --namespace=my-namespace
kubectl 创建 rolebinding rbd 的名字 --service是my-namespace这个命名空间下通过rolebinding绑定到clusterrole上，view是安装k8s的时候默认的角色 只读权限。

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=my-namespace: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
让所有sa都具有查看的权限，创建pod时用任何一个sa就只有查看的权限

（5）为所有 Service Account 授予超级用户权限
kubectl create clusterrolebinding serviceaccounts-view --clusterrole=cluster-admin --group=system:serviceaccounts

kubectl コマンド ライン ツールを使用してリソース オブジェクトを作成する

（1）在命名空间 rbac 中为用户 es 授权 admin ClusterRole：
kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=es --namespace=rbac
#对于mes这个用户，他对rbac这个命名空间具有admin权限，通过rolebinding绑定到admin这个ClusterRole上
 
（2）在命名空间 rbac 中为名为 myapp 的 Service Account 授予 view ClusterRole：
kubctl create rolebinding myapp-role-binding --clusterrole=view --serviceaccount=rbac:myapp --namespace=rbac
#对于myapp这个sa用户，他对rbac这个命名空间就只有查看的权限，通过rolebinding绑定到admin这个ClusterRole上
 
（3）在全集群范围内为用户 root 授予 cluster-admin ClusterRole：
kubectl create clusterrolebinding cluster-binding --clusterrole=cluster-admin --user=root
#对于root这个用户，对所有的名称空间都具有管理员权限，通过clusterrolebinding绑定到admin这个ClusterRole上

（4）在全集群范围内为名为 myapp 的 Service Account 授予 view ClusterRole：
kubectl create clusterrolebinding service-account-binding --clusterrole=view --serviceaccount=myapp
#对于myapp这个sa用户，对所有的名称空间都具有查看的权限，通过clusterrolebinding绑定到view这个ClusterRole上

yaml 文件进行 rbac 授权：https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac

k8s クラスターを操作する別のユーザーを制限する

ssl 认证 生成一个证书 
1 生成一个私钥 
[root@k8smaster secret]# cd /etc/kubernetes/pki/ 
[root@k8smaster pki]# (umask 077; openssl genrsa -out paopao.key 2048) 
Generating RSA private key, 2048 bit long modulus
.......................................................+++
.....................................................+++
e is 65537 (0x10001)

2 生成一个证书请求,并且生成证书
[root@k8smaster pki]# openssl req -new -key paopao.key -out paopao.csr -subj "/CN=paopao" 
[root@k8smaster pki]# openssl x509 -req -in paopao.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out paopao.crt -days 3650 					用ca这个机构颁发证书，paopao.crt这个证书是被ca.crt这个apiservion信任的
Signature ok
subject=/CN=paopao
Getting CA Private Key

在 kubeconfig 下新增加一个 lucky 这个用户 
1 把 paopao 这个用户添加到 kubernetes 集群中，可以用来认证 apiserver 的连接 
[root@k8smaster pki]# kubectl config set-credentials paopao --client-certificate=./paopao.crt --client-key=./paopao.key --embed-certs=true 
User "paopao" set.
#添加了一个用户paopao，用的客户端证书是paopao.crt，key是paopao.key。

[root@k8smaster pki]# vim /root/.kube/config	#不修改 进去查看刚才创建的用户
- name: paopao
  user:
 
2 在 kubeconfig 下新增加一个 lucky 这个账号 
[root@k8smaster pki]# kubectl config set-context paopao@kubernetes --cluster=kubernetes --user=paopao
Context "paopao@kubernetes" created.
这个上下文包括了k8s集群，用户是paopao

[root@k8smaster pki]# vim /root/.kube/config	#不修改 进去查看刚才创建的
- context:
    cluster: kubernetes
    user: paopao
  name: paopao@kubernetes
current-context: kubernetes-admin@kubernetes

3 切换账号到 paopao，默认没有任何权限 
[root@k8smaster pki]# kubectl config use-context paopao@kubernetes 
Switched to context "paopao@kubernetes".
[root@k8smaster pki]# kubectl get pods
Error from server (Forbidden): pods is forbidden: User "paopao" cannot list resource "pods" in API group "" in the namespace "default"
#没有权限！
[root@k8smaster pki]# kubectl config use-context kubernetes-admin@kubernetes 这个是集群用户，有所有权限 
把 user 这个用户通过 rolebinding 绑定到 clusterrole 上,授予权限,权限只是在 paopao 这个名称空间有效 

1 把 lucky 这个用户通过 rolebinding 绑定到 clusterrole 上 
[root@k8smaster ~]# kubectl create ns paopao 
namespace/paopao created
[root@k8smaster ~]# kubectl create rolebinding paopao -n paopao --clusterrole=cluster-admin --user=paopao
rolebinding.rbac.authorization.k8s.io/paopao created

2 测试是否有权限 
[root@k8smaster ~]# kubectl config use-context paopao@kubernetes 
Switched to context "paopao@kubernetes".
[root@k8smaster ~]# kubectl get pods					没有权限操作其他名称空间 
Error from server (Forbidden): pods is forbidden: User "paopao" cannot list resource "pods" in API group "" in the namespace "default"
[root@k8smaster ~]# kubectl get pods -n paopao			有权限操作这个名称空间 
No resources found in paopao namespace.

添加一个 paopao 的普通用户 
[root@k8smaster ~]# useradd paopao
[root@k8smaster ~]# cp /root/.kube/config /root/testconfig
[root@k8smaster ~]# vim /root/testconfig
#删除以下内容
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes

- name: kubernetes-admin
  user:
    client-certificate-data: 
#下面的两大行密钥也删除

[root@k8smaster ~]# cp -ar /root/.kube/ /home/paopao/ 
[root@k8smaster ~]# cp -ar /root/testconfig /home/paopao/.kube/config 
cp: overwrite ‘/home/paopao/.kube/config’? y
[root@k8smaster ~]# rm -f /home/paopao/.kube/testconfig 
[root@k8smaster ~]# chown -R paopao.paopao /home/paopao/ 
[root@k8smaster ~]# su - paopao
Last login: Sat Jul 16 00:47:20 PDT 2022 on pts/0
[paopao@k8smaster ~]$ kubectl get pods -n paopao
No resources found in paopao namespace.
#只能查看paopao这个命名空间

最後に書く

作成するのは簡単ではありません。コンテンツが役立つと思われる場合は、3 つのリンクをフォローしてサポートしてください。間違いがあればコメントで指摘していただければ修正します！

現在更新中のシリーズ：TBD

ご覧いただきありがとうございます。記事は個人的な理解が混在しています。エラーがある場合は、私に連絡して指摘してください〜