咱们晓得对于资源对象的操作都是通过 APIServer 进行的，那么集群是怎么晓得咱们的申请就是非法的申请呢？这个就须要理解 Kubernetes的认证鉴权流程

API 对象

在讲认证鉴权之前，咱们还须要再去了解下 Kubernetes 集群中的对象，咱们晓得，在 Kubernetes 集群中，Kubernetes 对象是咱们长久化的实体，就是最终存入 etcd 中的数据。咱们间接编写的 YAML 文件，通过 kubectl 来提交的资源清单文件，而后创立的对应的资源对象，那么它到底是如何将咱们的 YAML 文件转换成集群中的一个 API 对象的呢？

这个就须要去理解下申明式 API的设计，Kubernetes API 是一个以 JSON 为次要序列化形式的 HTTP 服务，除此之外也反对 Protocol Buffers 序列化形式，次要用于集群外部组件间的通信。Kubernetes API 文档能够参考官网https://kubernetes.io/docs/re...

为了可扩展性，Kubernetes 在不同的 API 门路（比方/api/v1 或者 /apis/batch）上面反对了多个 API 版本，不同的 API 版本意味着不同级别的稳定性和反对：

  • Alpha 级别，例如 v1alpha1 默认状况下是被禁用的，能够随时删除对性能的反对，所以要慎用
  • Beta 级别，例如 v2beta1 默认状况下是启用的，示意代码曾经通过了很好的测试，然而对象的语义可能会在随后的版本中以不兼容的形式更改
  • 稳固级别，比方 v1 示意曾经是稳固版本了，也会呈现在后续的很多版本中。

在 Kubernetes 集群中，一个 API 对象在 Etcd 里的残缺资源门路，是由：Group（API 组）、Version（API 版本）和 Resource（API 资源类型）三个局部组成的。通过这样的构造，整个 Kubernetes 里的所有 API 对象，实际上就能够用如下的树形构造示意进去：

从上图中咱们也能够看出 Kubernetes 的 API 对象的组织形式，在顶层，咱们能够看到有一个外围组（因为历史起因，是 /api/v1 下的所有内容而不是在 /apis/core/v1 上面）和命名组（门路 /apis/$NAME/$VERSION）和零碎范畴内的实体，比方 /metrics。咱们也能够用上面的命令来查看集群中的 API 组织模式：

[root@k8s-master ~]# kubectl get --raw /{  "paths": [    "/api",    "/api/v1",    "/apis",    "/apis/",    ...    "/version"  ]}

比方咱们来查看外围组下的资源对象，同样咱们还是能够通过 kubectl 来查问数据，这外面咱们能够看到外围组上面的资源对象和对应操作

[root@k8s-master ~]# kubectl get --raw /api/v1 | python -m json.tool{    "groupVersion": "v1",    "kind": "APIResourceList",    "resources": [        {            "kind": "Binding",            "name": "bindings",            "namespaced": true,            "singularName": "",            "verbs": [                "create"            ]        },        {            "kind": "ComponentStatus",            "name": "componentstatuses",            "namespaced": false,            "shortNames": [                "cs"            ],            "singularName": "",            "verbs": [                "get",                "list"            ]        },        {            "kind": "ConfigMap",            "name": "configmaps",            "namespaced": true,            "shortNames": [                "cm"            ],            "singularName": "",            "storageVersionHash": "qFsyl6wFWjQ=",            "verbs": [                "create",                "delete",                "deletecollection",                "get",                "list",                "patch",                "update",                "watch"            ]        },        ...        {            "kind": "Service",            "name": "services/status",            "namespaced": true,            "singularName": "",            "verbs": [                "get",                "patch",                "update"            ]        }

然而这个操作和咱们平时操作 HTTP 服务的形式不太一样，这里咱们能够通过 kubectl proxy 命令来开启一个代理http服务对 apiserver 进行拜访：

[root@k8s-master ~]# kubectl proxyStarting to serve on 127.0.0.1:8001

而后从新开启一个新的终端，咱们能够通过如下代理服务形式来拜访apiserver的接口，比方咱们拜访查问某个命名空间下pod资源对象的接口

[root@k8s-master ~]# curl http://127.0.0.1:8001/api/v1/namespaces/default/pods{  "kind": "PodList",  "apiVersion": "v1",  "metadata": {    "selfLink": "/api/v1/namespaces/default/pods",    "resourceVersion": "9109616"  },  "items": [    {      "metadata": {        "name": "nginx-deploy-75c7f965d8-hnmvn",        "generateName": "nginx-deploy-75c7f965d8-",        "namespace": "default",        "selfLink": "/api/v1/namespaces/default/pods/nginx-deploy-75c7f965d8-hnmvn",        "uid": "574ac979-41b8-460f-afaf-d29155911ba3",        "resourceVersion": "6786396",        "creationTimestamp": "2021-05-10T03:30:07Z",        "labels": {          "app": "nginx",          "pod-template-hash": "75c7f965d8"        },        "ownerReferences": [          {            "apiVersion": "apps/v1",            "kind": "ReplicaSet",            "name": "nginx-deploy-75c7f965d8",            "uid": "25bdae05-87e9-41e0-bcde-6bfeda87047c",            "controller": true,            "blockOwnerDeletion": true          }        ],        ...

通常，Kubernetes API 反对通过规范 HTTP  POST、PUT、DELETE 和 GET 在指定 PATH 门路上创立、更新、删除和检索操作，并应用 JSON 作为默认的数据交互格局。

Kubernetes认证

下面咱们应用了kubectl或者kubectl proxy的形式，都可能顺利获取到apiserver的资源对象的数据，这是因为它们曾经顺利通过了Kubernetes的认证鉴权组件
Kubernetes API的申请从发动到操作存储层的流程如图

上面咱们剖析下kubectl、kubectl proxy、pod拜访apiserver的认证形式

kubectl拜访apiserver

kubectl应用的认证形式是clientCA认证，X509认证是Kubernetes组件间默认应用的认证形式，同时也是kubectl客户端对应的kube-config中常常应用到的拜访凭证。它是一个比拟平安的形式，访问者会应用由集群CA签发的，或是增加在apiserver配置中的授信CA签发的客户端证书去拜访apiserver。apiserver在接管到申请后，会进行TLS的握手流程。
除了验证证书的合法性，apiserver还会校验客户端证书的申请源地址等信息，开启双向认证。
比方咱们查看下咱们kubectl的证书信息

[root@k8s-master ~]# cat ~/.kube/configapiVersion: v1contexts:- context:    cluster: kubernetes    user: kubernetes-admin  name: kubernetes-admin@kubernetescurrent-context: kubernetes-admin@kubernetesusers:- name: kubernetes-admin  user:    client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURFekNDQWZ1Z0F3SUJBZ0lJVmxIbDlTalNvdFF3RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TVRBME1EY3hNVFF6TXpsYUZ3MHlNakEwTURjeE1UUXpOREZhTURReApGekFWQmdOVkJBb1REbk41YzNSbGJUcHRZWE4wWlhKek1Sa3dGd1lEVlFRREV4QnJkV0psY201bGRHVnpMV0ZrCmJXbHVNSUlCSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4QU1JSUJDZ0tDQVFFQXFzVnlQc2RQRGlEYW9FNWcKZWxOQjV4ZHJoZCs1eEd5RUJFbGpUY2tMb3JPQlN6SjE3Z2JpY0VSaXRQLzh1YVpmVk9ISnZ0Y2tyZUpGa3NHNgp2Ujc5YUk4d3k0elUreEk0ZzdzK2ZrTFRsK1QrR2xaSWlQaXN3a2RQZE9ad0REUDBKdDQ5NjljVzFndVJ6UTVQCmhpSjRTcE96Z0dmeFJGQWpFTUFCNktJcXBWYjlrbmV4d0xHVDRRNTZNS1JvV294UytEaFBQZFk4bUlVR3pHZ0oKbkw1bEl1Mjl2a0FmWG1vZEdZMVFUNkszSXU3NmFhWXl0TTVRUTZZVnFwekxXU0lYOFN2L0E0dlFqVDlTSDY5eQptQ1RmQ0lXWjVTRGZ4VTlvQ0p5RGpKTmpBdUErNWJONUpxMDFEYjhjK0hjTHVHUENBRVJUVnBZU3docWx1T0lFCk40SU9Md0lEQVFBQm8wZ3dSakFPQmdOVkhROEJBZjhFQkFNQ0JhQXdFd1lEVlIwbEJBd3dDZ1lJS3dZQkJRVUgKQXdJd0h3WURWUjBqQkJnd0ZvQVV6RmZHVHJhMjRVa3hzM2NReWJzSnprT2R2UXN3RFFZSktvWklodmNOQVFFTApCUUFEZ2dFQkFDRHUwQ3g5Qk1NdjdUMnh6T3gzTDNNczk5NTdKMDY3WDVhbTZnZW4yaXltekViMkNldG51REdoCnFMWW5MZnBOZ1FOQ1pTbkg5dzZIYjdWenRMTzlheXZjejcvRVlRVkpyOVN0MzdtZDc0d3dKY1AvZWY1b2ZEbkgKVTVJaXZKK1RuM3REeGhlVVU5VlBFSkdCbFZmd3N0UmxJZ3NWclR0TkVnNGYzaW04azZzNlRTTGV5Sis4Y21zdgpwTmYyRDNpWWw3aEhBTGJwS2tFWVEya2xSY0IyRDFSL1Fhd2o4WWoyUGJ4cEZOU0t4QmQ4S09mcGVaMWQ5ZmpiCmZMbUxGU29rZjk1b0lrTk9TSGpUanVDNmNaNGVHczU0bjhaMmhnMWZia1R0Y2pJK1ROZi9nY29FNExvM3JhaDgKbW1sa1Qxdit4T3hKUWpkbkdwT2FSNytINFkwblY5dz0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=    client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBcXNWeVBzZFBEaURhb0U1Z2VsTkI1eGRyaGQrNXhHeUVCRWxqVGNrTG9yT0JTekoxCjdnYmljRVJpdFAvOHVhWmZWT0hKdnRja3JlSkZrc0c2dlI3OWFJOHd5NHpVK3hJNGc3cytma0xUbCtUK0dsWkkKaVBpc3drZFBkT1p3RERQMEp0NDk2OWNXMWd1UnpRNVBoaUo0U3BPemdHZnhSRkFqRU1BQjZLSXFwVmI5a25leAp3TEdUNFE1Nk1LUm9Xb3hTK0RoUFBkWThtSVVHekdnSm5MNWxJdTI5dmtBZlhtb2RHWTFRVDZLM0l1NzZhYVl5CnRNNVFRNllWcXB6TFdTSVg4U3YvQTR2UWpUOVNINjl5bUNUZkNJV1o1U0RmeFU5b0NKeURqSk5qQXVBKzViTjUKSnEwMURiOGMrSGNMdUdQQ0FFUlRWcFlTd2hxbHVPSUVONElPTHdJREFRQUJBb0lCQUdLQnVzRVQzenBiSVVIUApkRCtidnl3NmlqK1RLbWx2MzBkSnZncWtxaDJVUmtUR090aXZCL2VTdXcyRmpKYmFyYXNkQTI4ZVUzNHFROC9BCkNLUUhPRTRVS3lWL2Uydkl1dWppSGM1ZlpnYjhoTWRVZGtyc2gxc2FIMjlqYmNiY1FUNGFmTVdLTVJZUFhtOVcKamZEbCtWV3JsYVBBVWFBQ1NmZmppalpUTlI1aCtuSUxxazdLQ3dUelRTRk1FNmNpS3g3NkhJZ08wODlhSzJGTgpqNWpLTjRhdWtSSTQyMnNiYmFvRGNsMXVpNVFtaHFVU0xCVVQvemVhTHM0MXJrN2w4MWNtQXhYQll0YXRwb1A0Ci84dDQzSkMyRVdYQU5BZDQ1cW1jbzVBUmZoMUZJMWo4ejB3dFZpakhDSmFIMmo4TjhGTHh3YzhZL0ttNGphMncKcVVyK0dhRUNnWUVBei95dVJMUDBBbWwvRXhLN0oxVUpERnJGbG5GTHVsRmVDM2dwWFRCL0NxUXFOL1BkbDVDdgpKbVpCV3VhTXArWEJna0NMZE5UV1BNMGFIUEd3aExKUWZXa1ZYc1lCM2VENllwM0pXVGR1dmJvbVVuRzY1TC9yCnF2WTVSUy83WWNmRnZtbVNNYVAxeCsxUDFEQWVUWHBvdllBczlIS2U3RFh4UUUxL3BEOHEwTzBDZ1lFQTBqRngKSlpQU1J4RE5tNVNaTzNsYUZwVDJKdGJQdDUvdUtXRjAraDZvWlNKaDlPVjhhaVM5NlRPRStYREYwaHk5ZVBMbAp6a1NFQ0hEOEE3ZVF0OWc1VGc2c3lCWkpWMXJzYUN0YjRCWGRpcU1jSGE4SWhLQW9ySnpxYldGTXZmdG1WMjc5CjMrVldGaW13dnBuTzNWaHhnQ3lLWjRhRjdaNkV2T1ZDb3IzNDVBc0NnWUVBeUlkME1qTmFtUlREKzB5OCsxQW0KZUMzd2dYdGNxeGdXVjNLVVZ4QVIvTjJKQXdkeDU5Y011RFl3M3dhWUtLMEJwS2E4am5sQzBiNWlaZk8wNEV2WQpCUUpUSTF3L29vQnVpTFJlMUZENHlaNTNvbGVhL1QvNVpZMGViSkcxaW5JRk92QW9qd25wUjhpTGhpYWFvTkxiCnQ1R2tSazlZNEorbHFmek9penFIK29VQ2dZQUp0aWNZS1dCSjBFanZxMG41S1g0MEZPWGFuWW96WGJ4UFJTVjIKZVB3bTBCUGVrTXZTeTZmS29vcStTNnVZTGFQRGR0V1BWak1UZ01Ua0Z4TWtxMlRhYW1zcFEzNVgvdWQxV0t1QwpDd0NWYXp2ZFV6ejlnN2pkWU5La0F4N2NtRVQrUFM2VnJhN3dqelNQV2VQbzdqRXdUdDZHTWZ6MklhRFlhVzlPCnZhQkdTUUtCZ0dEaGdvK3BucWFrZmhVRE15bWxwQ3ZiNWZXS000RzJWbDFHZEdaSlFSWEpPR0hqbjlyNWZuQzEKdGx4d3BBN2NucjNPalRLYVRYeVM1SzA0QlVzQ0l2UFZmZVZlMW9ydm9rR3ZkNGJxUlFab3AvVlFzWnI2RGpnTApqUjV4UzBOdXJnR2QzVVEwRHFhL0xOQW9mMEFOdG9nTHM1Vm1VL1pueDA2L3dndHN6empnCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==

默认咱们应用kubectl命令行，应用的默认上下文是kubernetes-admin@kubernetes，这个上下文应用的kubernetes用户是kubernetes-admin
这个用户对应的证书中是蕴含认证信息的

echo -n "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURFekNDQWZ1Z0F3SUJBZ0lJVmxIbDlTalNvdFF3RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TVRBME1EY3hNVFF6TXpsYUZ3MHlNakEwTURjeE1UUXpOREZhTURReApGekFWQmdOVkJBb1REbk41YzNSbGJUcHRZWE4wWlhKek1Sa3dGd1lEVlFRREV4QnJkV0psY201bGRHVnpMV0ZrCmJXbHVNSUlCSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4QU1JSUJDZ0tDQVFFQXFzVnlQc2RQRGlEYW9FNWcKZWxOQjV4ZHJoZCs1eEd5RUJFbGpUY2tMb3JPQlN6SjE3Z2JpY0VSaXRQLzh1YVpmVk9ISnZ0Y2tyZUpGa3NHNgp2Ujc5YUk4d3k0elUreEk0ZzdzK2ZrTFRsK1QrR2xaSWlQaXN3a2RQZE9ad0REUDBKdDQ5NjljVzFndVJ6UTVQCmhpSjRTcE96Z0dmeFJGQWpFTUFCNktJcXBWYjlrbmV4d0xHVDRRNTZNS1JvV294UytEaFBQZFk4bUlVR3pHZ0oKbkw1bEl1Mjl2a0FmWG1vZEdZMVFUNkszSXU3NmFhWXl0TTVRUTZZVnFwekxXU0lYOFN2L0E0dlFqVDlTSDY5eQptQ1RmQ0lXWjVTRGZ4VTlvQ0p5RGpKTmpBdUErNWJONUpxMDFEYjhjK0hjTHVHUENBRVJUVnBZU3docWx1T0lFCk40SU9Md0lEQVFBQm8wZ3dSakFPQmdOVkhROEJBZjhFQkFNQ0JhQXdFd1lEVlIwbEJBd3dDZ1lJS3dZQkJRVUgKQXdJd0h3WURWUjBqQkJnd0ZvQVV6RmZHVHJhMjRVa3hzM2NReWJzSnprT2R2UXN3RFFZSktvWklodmNOQVFFTApCUUFEZ2dFQkFDRHUwQ3g5Qk1NdjdUMnh6T3gzTDNNczk5NTdKMDY3WDVhbTZnZW4yaXltekViMkNldG51REdoCnFMWW5MZnBOZ1FOQ1pTbkg5dzZIYjdWenRMTzlheXZjejcvRVlRVkpyOVN0MzdtZDc0d3dKY1AvZWY1b2ZEbkgKVTVJaXZKK1RuM3REeGhlVVU5VlBFSkdCbFZmd3N0UmxJZ3NWclR0TkVnNGYzaW04azZzNlRTTGV5Sis4Y21zdgpwTmYyRDNpWWw3aEhBTGJwS2tFWVEya2xSY0IyRDFSL1Fhd2o4WWoyUGJ4cEZOU0t4QmQ4S09mcGVaMWQ5ZmpiCmZMbUxGU29rZjk1b0lrTk9TSGpUanVDNmNaNGVHczU0bjhaMmhnMWZia1R0Y2pJK1ROZi9nY29FNExvM3JhaDgKbW1sa1Qxdit4T3hKUWpkbkdwT2FSNytINFkwblY5dz0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo="|base64 -d|openssl x509 -textcertificate:    Data:        Version: 3 (0x2)        Serial Number: 6220005401490006740 (0x5651e5f528d2a2d4)    Signature Algorithm: sha256WithRSAEncryption        Issuer: CN=kubernetes        Validity            Not Before: Apr  7 11:43:39 2021 GMT            Not After : Apr  7 11:43:41 2022 GMT        Subject: O=system:masters, CN=kubernetes-admin  ...

其中Subject: O=system:masters, CN=kubernetes-admin别离代表O用户组和CN用户，kubernetes基于RBAC对该用户和组配置了对应的权限

kubectl proxy拜访apiserver

kubectl proxy应用的是RequestHeader认证，在该种拜访模式下, 咱们是以http的形式发动申请到代理服务的, 此时, 代理服务会将该申请发送给 kube-apiserver, 在此之前, 代理会将发送给 kube-apiserver 的申请头里退出证书信息
apiserver须要配置：

  • --requestheader-username-headers=X-Remote-User
  • --requestheader-group-headers=X-Remote-Group
  • --requestheader-extra-headers-prefix=X-Remote-Extra-
  • --requestheader-client-ca-file：避免头部坑骗
  • --requestheader-allowed-names：设置容许的CN列表
  • --proxy-client-cert-file：客户端证书
  • --proxy-client-key-file：客户端私钥
   [root@k8s-master ~]# vim /etc/kubernetes/manifests/kube-apiserver.yaml   ...     - --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt    - --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key    - --requestheader-allowed-names=front-proxy-client    - --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt    - --requestheader-extra-headers-prefix=X-Remote-Extra-    - --requestheader-group-headers=X-Remote-Group    - --requestheader-username-headers=X-Remote-User   ...

咱们查看对应的proxy-client-cert-file证书，获取用户信息

[root@k8s-master ~]# cat /etc/kubernetes/pki/front-proxy-client.crt|openssl x509 -textCertificate:    Data:        Version: 3 (0x2)        Serial Number: 1421614817980964257 (0x13ba9725192fdda1)    Signature Algorithm: sha256WithRSAEncryption        Issuer: CN=front-proxy-ca        Validity            Not Before: Apr  7 11:43:40 2021 GMT            Not After : Apr  7 11:43:40 2022 GMT        Subject: CN=front-proxy-client

能够看到对应的CN是front-proxy-client，咱们在apiserver中曾经配置了- --requestheader-allowed-names=front-proxy-client是能够认证通过的

Pod拜访apiserver

Pod拜访apiserver应用的是ServiceAccountAuth认证，serviceaccount是k8s中惟一可能通过API形式治理的apiserver拜访凭证，通常用于pod中的业务过程与apiserver的交互，ServiceAccount解决Pod在集群外面的身份认证问题，认证应用的受权信息存在secret外面（由SecretAccount Controller自行创立）
当一个namespace创立实现后，会同时在该namespace下生成名为default的serviceaccount和对应Secret：

[root@k8s-master ~]# kubectl get sa default -o yamlapiVersion: v1kind: ServiceAccountmetadata:  creationTimestamp: "2021-04-07T11:44:12Z"  name: default  namespace: default  resourceVersion: "379"  selfLink: /api/v1/namespaces/default/serviceaccounts/default  uid: 3493e0f4-a87c-4c0e-a373-3c117d205d8dsecrets:- name: default-token-s46zd
[root@k8s-master ~]# kubectl get secret default-token-s46zd -o yamlapiVersion: v1data:  ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM1ekNDQWMrZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeE1EUXdOekV4TkRNek9Wb1hEVE14TURRd05URXhORE16T1Zvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBSlFWCjNmRmVraUdmL3ZDK1JPNFR4SC9QbkRhMmJINi9lRFAzNUc1SXppUnladmpUWWtNeGVyOHIrTWdndCtCN05oc28Ka0ZCVVNCVUhrbVhHZFFBUHRjNTJocVdGRlhtZk10TzBhNzZBTWNCdFZUa2hPZDRxc3NPcy9jUndVcGxYKytteApLcW9FdDc0eFBhRnJxRzIyeDVEN011Y3lYQmtxQk4vWGRKcThKNU5xTWhHd2EvbjVtbWUxYmRrdGh3UWd1SnZzCkc2THRBZGZhRWdXbWxnUVFUMWZHNkhVV3g0L085aTJSNEhIU1VXMDFmTnUwaGFVekNJcE04VERLMk9DbDJYN04KcWE3QitGZDlZR1krUVdhNWVMZk9nMFJUcTJOb210M1E5WWVGWHJKZDJMOHlpc3VsbjM0ZDNxZjFQakxtMkdJQwpQS01XenBVaWJxbkpNb0RvdjYwQ0F3RUFBYU5DTUVBd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZNeFh4azYydHVGSk1iTjNFTW03Q2M1RG5iMExNQTBHQ1NxR1NJYjMKRFFFQkN3VUFBNElCQVFBdW5WUXYvTnhnN2JCYXBiVWRVT2s4UWhkclZkbXFGVUlCWnlQN0FUMlh5eVNlMG8xVwp4dEU3c1NyWlQvZDJUTzJseFRLM0NQRVU2dW9uMDQ1amhyd1N1dGNVa3llMUZVcnF6aWNTa1luZjhnVFdOMmtlCnpUdWJ5OUowcVZFRVErc2cvU2Q1bERVUm9LSHAyVXRLZzdrbVRzT3d3U2ppVnlVZEdmMGcrZ2djUU9iMjFvNVgKYUtoOUtIQUdBVDRvQnlOdTY0STJEaWV0QkRkWWdsL3B5cTgwcCtwVTlLSDJObEZrMERhc01uU2I0eEE1M2U3RApJQVJua0JGOFNuSXR2a3pacFFTVWhXNVpJT2IvdjdOcWZxalhuTE8rdUx4czRPSllXL3V5TzBpMEkrYUF5RWRYClUyUkMzZjIyUHV1VmNnWmZ6ck5vUzU5dnQwVVlVM1FRcURqMgotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==  namespace: ZGVmYXVsdA==  token: ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNklraDZZMnB4VlhCbk5ubFBVa3AxVVZwblYwbGthMmhOZG14TVpHeHdOa1pGVFdvMVFXUkhjbUpPWldNaWZRLmV5SnBjM01pT2lKcmRXSmxjbTVsZEdWekwzTmxjblpwWTJWaFkyTnZkVzUwSWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXVZVzFsYzNCaFkyVWlPaUprWldaaGRXeDBJaXdpYTNWaVpYSnVaWFJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5elpXTnlaWFF1Ym1GdFpTSTZJbVJsWm1GMWJIUXRkRzlyWlc0dGN6UTJlbVFpTENKcmRXSmxjbTVsZEdWekxtbHZMM05sY25acFkyVmhZMk52ZFc1MEwzTmxjblpwWTJVdFlXTmpiM1Z1ZEM1dVlXMWxJam9pWkdWbVlYVnNkQ0lzSW10MVltVnlibVYwWlhNdWFXOHZjMlZ5ZG1salpXRmpZMjkxYm5RdmMyVnlkbWxqWlMxaFkyTnZkVzUwTG5WcFpDSTZJak0wT1RObE1HWTBMV0U0TjJNdE5HTXdaUzFoTXpjekxUTmpNVEUzWkRJd05XUTRaQ0lzSW5OMVlpSTZJbk41YzNSbGJUcHpaWEoyYVdObFlXTmpiM1Z1ZERwa1pXWmhkV3gwT21SbFptRjFiSFFpZlEuWHc3Rm4zWURoTlViYWNMOVdMVW1ISFQzbzkyZ2d2c0t0dzdPY21PTUhyd2ZDTnlPUFRIWTFKTUtCRkpCZkIzcmhjdURncHI2dHBpQm1BN0pnUzkwRTVhNG4zU1VoU0pscEE4eElZWU90aklJSFhaV25rYVg3T1c0WkRwU2RIVzNienNyOHBBc09SS2diTENzZ18yRlBmRGhybHRQMjFKNnZoOHZMUGlfVVJlTmtiSVM4WlgzcERFNTV2eHZlRkE1Zkk1S2NqLVJKdnRpOFQ3TUc5WjQxZU56OXlyWVd5SkRpenh5RUlLR0tEVnVIUjNyLXpvWm9icHhvQU1BcUc2aFN6NkhXUUkzVG45anVXcmVWTGJWYk9qUktzTmF4ZVNqOU5BSTBsZXRzQTJPVFVGcUF3M1drU3E0MnRZOE5fcm5NbkZuN1R3U3VqQk5hVmlPSl9xQi13kind: Secretmetadata:  annotations:    kubernetes.io/service-account.name: default...

对应的Secret里：data字段有两块数据：ca.crt用于对服务端的校验，token用于Pod的身份认证，它们都是用base64编码过的
Pod创立的时候，Admission Controller会依据指定的ServiceAccount把对应secret的ca.crt和token文件挂载到固定目录/var/run/secrets/kubernetes.io/serviceaccount下

    volumeMounts:    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount      name: default-token-s46zd      readOnly: true

Pod要拜访apiserver的时候，默认利用Secret其中的token文件来认证Pod的身份，利用ca.crt校验服务端，Pod身份被认证非法后，其权限须要通过RBAC来配置

Kubernetes鉴权（RBAC）

下面咱们介绍了 Kubernetes 所有资源对象都是模型化的 API 对象，容许执行 CRUD(Create、Read、Update、Delete) 操作(也就是咱们常说的增、删、改、查操作)，比方上面的这些资源：

  • Pods
  • ConfigMaps
  • Deployments
  • Nodes
  • Secrets
  • Namespaces
  • ......
    对于下面这些资源对象的可能存在的操作有：
  • create
  • get
  • delete
  • list
  • update
  • edit
  • watch
  • exec
  • patch

在更下层，这些资源和 API Group 进行关联，比方 Pods 属于 Core API Group，而 Deployements 属于 apps API Group，当初咱们要在 Kubernetes 中通过 RBAC 来对资源进行权限治理，除了下面的这些资源和操作以外，咱们还须要理解另外几个概念：

  • Rule：规定，规定是一组属于不同 API Group 资源上的一组操作的汇合
  • Role 和 ClusterRole：角色和集群角色，这两个对象都蕴含下面的 Rules 元素，二者的区别在于，在 Role 中，定义的规定只实用于单个命名空间，也就是和 namespace 关联的，而 ClusterRole 是集群范畴内的，因而定义的规定不受命名空间的束缚。另外 Role 和 ClusterRole 在Kubernetes 中都被定义为集群外部的 API 资源，和咱们后面学习过的 Pod、Deployment 这些对象相似，都是咱们集群的资源对象，所以同样的能够应用 YAML 文件来形容，用 kubectl 工具来治理

  • Subject：主题，对应集群中尝试操作的对象，集群中定义了3种类型的主题资源：

    • User Account：用户，这是有内部独立服务进行治理的，管理员进行私钥的调配，用户能够应用 KeyStone 或者 Goolge 帐号，甚至一个用户名和明码的文件列表也能够。对于用户的治理集群外部没有一个关联的资源对象，所以用户不能通过集群外部的 API 来进行治理
    • Group：组，这是用来关联多个账户的，集群中有一些默认创立的组，比方 cluster-admin
    • Service Account：服务帐号，通过 Kubernetes API 来治理的一些用户帐号，和 namespace 进行关联的，实用于集群外部运行的应用程序，须要通过 API 来实现权限认证，所以在集群外部进行权限操作，咱们都须要应用到 ServiceAccount
  • RoleBinding 和 ClusterRoleBinding：角色绑定和集群角色绑定，简略来说就是把申明的 Subject 和咱们的 Role 进行绑定的过程（给某个用户绑定上操作的权限），二者的区别也是作用范畴的区别：RoleBinding 只会影响到以后 namespace 上面的资源操作权限，而 ClusterRoleBinding 会影响到所有的 namespace。

接下来咱们来通过几个简略的示例，来演示下在 Kubernetes 集群中如何应用 RBAC。

只能拜访某个 namespace 的普通用户

咱们想要创立一个 User Account，只能拜访default这个命名空间，对应的用户信息如下所示：

username: wangcsgroup: imonkey

创立用户凭证

咱们后面曾经提到过，Kubernetes 没有 User Account 的 API 对象，不过要创立一个用户帐号的话也是挺简略的，利用管理员调配给你的一个私钥就能够创立了，这个咱们能够参考官网文档中的办法，这里咱们来应用 OpenSSL 证书来创立一个 User
给用户 wangcs 创立一个私钥，命名成 wangcs.key：

[root@k8s-master k8s-rbac]# openssl genrsa -out wangcs.key 2048Generating RSA private key, 2048 bit long modulus....+++...................+++e is 65537 (0x10001)

应用咱们刚刚创立的私钥创立一个证书签名申请文件：wangcs.csr，要留神须要确保在-subj参数中指定用户名和组(CN示意用户名，O示意组)：

[root@k8s-master k8s-rbac]# openssl req -new -key wangcs.key -out wangcs.csr -subj "/CN=wangcs/O=imonkey"

而后找到咱们的 Kubernetes 集群的 CA 证书，咱们应用的是 kubeadm 装置的集群，CA 相干证书位于 /etc/kubernetes/pki/ 目录上面，咱们会利用该目录上面的 ca.crt 和 ca.key两个文件来批准下面的证书申请。生成最终的证书文件，咱们这里设置证书的有效期为 100 天：

[root@k8s-master k8s-rbac]# openssl x509 -req -in wangcs.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out wangcs.crt -days 100Signature oksubject=/CN=wangcs/O=imonkeyGetting CA Private Key

当初查看咱们以后文件夹上面是否生成了一个证书文件：

[root@k8s-master k8s-rbac]# lswangcs.crt  wangcs.csr  wangcs.key

当初咱们能够应用刚刚创立的证书文件和私钥文件在集群中创立新的凭证和上下文(Context):

[root@k8s-master]# kubectl config set-credentials wangcs --client-certificate=/root/k8s-rbac/wangcs.crt --client-key=/root/k8s-rbac/wangcs.keyUser "wangcs" set.

咱们能够看到一个用户 wangcs 创立了，而后为这个用户设置新的 Context，咱们这里指定特定的一个 namespace：

[root@k8s-master ~]# kubectl config set-context wangcs-context --cluster=kubernetes --namespace=default --user=wangcsContext "wangcs-context" created.

到这里，咱们的用户 wangcs 就曾经创立胜利了，当初咱们应用以后的这个配置文件来操作 kubectl 命令的时候，应该会呈现谬误，因为咱们还没有为该用户定义任何操作的权限呢：

[root@k8s-master ~]# kubectl get pods --context=wangcs-contextError from server (Forbidden): pods is forbidden: User "wangcs" cannot list resource "pods" in API group "" in the namespace "default"

创立角色

用户创立实现后，接下来就须要给该用户增加操作权限，咱们来定义一个 YAML 文件，创立一个容许用户操作 Deployment、Pod、ReplicaSets 的角色，如下定义：(wangcs-role.yaml)

apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:  name: wangcs-role  namespace: defaultrules:- apiGroups: ["", "apps"]  resources: ["deployments", "replicasets", "pods"]  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] # 也能够应用['*']

其中 Pod 属于core这个 API Group，在 YAML 中用空字符就能够，而 Deployment 和 ReplicaSet 当初都属于 apps 这个 API Group（如果不晓得则能够用 kubectl explain 命令查看），所以 rules 上面的 apiGroups 就综合了这几个资源的 API Group：["", "apps"]，其中 verbs 就是咱们下面提到的能够对这些资源对象执行的操作，咱们这里须要所有的操作方法，所以咱们也能够应用['*']来代替，而后间接创立这个 Role：

[root@k8s-master k8s-rbac]# kubectl apply -f wangcs-role.yaml role.rbac.authorization.k8s.io/wangcs-role created

创立角色权限绑定

Role 创立实现了，然而很显著当初咱们这个 Role 和咱们的用户 wangcs 还没有任何关系，对吧？这里就须要创立一个 RoleBinding 对象，在 default 这个命名空间上面将下面的 wangcs-role 角色和用户 wangcs 进行绑定：（wangcs-rolebinding.yaml）

apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:  name: wangcs-rolebinding  namespace: defaultsubjects:- kind: User  name: wangcs  apiGroup: ""roleRef:  kind: Role  name: wangcs-role  apiGroup: rbac.authorization.k8s.io  # 留空字符串也能够，则应用以后的apiGroup

下面的 YAML 文件中咱们看到了 subjects 字段，这里就是咱们下面提到的用来尝试操作集群的对象，这里对应下面的 User 帐号 wangcs，应用kubectl 创立下面的资源对象：

[root@k8s-master k8s-rbac]# kubectl apply -f wangcs-rolebinding.yaml rolebinding.rbac.authorization.k8s.io/wangcs-rolebinding created

测试

当初咱们应该能够下面的 wangcs-context 上下文来操作集群了：

[root@k8s-master ~]# kubectl get pods --context=wangcs-contextNAME                            READY   STATUS    RESTARTS   AGEnginx-deploy-75c7f965d8-hnmvn   1/1     Running   0          11dnginx-deploy-75c7f965d8-xtdv9   1/1     Running   0          11d

咱们能够胜利拜访default命名空间的pod对象，如果咱们在前面加上一个-n kube-system试看看呢？

[root@k8s-master ~]# kubectl get pods --context=wangcs-context -n kube-systemError from server (Forbidden): pods is forbidden: User "wangcs" cannot list resource "pods" in API group "" in the namespace "kube-system"

如果去获取其余的资源对象呢：

[root@k8s-master ~]# kubectl get configmaps  --context=wangcs-contextError from server (Forbidden): configmaps is forbidden: User "wangcs" cannot list resource "configmaps" in API group "" in the namespace "default"

咱们能够看到没有权限获取，因为咱们并没有为以后操作用户指定configmap的拜访权限，是合乎咱们的预期的。这样咱们就创立了一个只有单个命名空间拜访权限的一般 User 。

只能拜访某个 namespace 的 ServiceAccount

下面咱们创立了一个只能拜访某个命名空间上面的普通用户，咱们后面也提到过 subjects 上面还有一种类型的主题资源：ServiceAccount，当初咱们来创立一个集群外部的用户只能操作 default 这个命名空间上面的 pods 和 deployments，首先来创立一个 ServiceAccount 对象：

[root@k8s-master ~]# kubectl create sa wangcs-saserviceaccount/wangcs-sa created

当然咱们也能够定义成 YAML 文件的模式来创立：

apiVersion: v1kind: ServiceAccountmetadata:  name: wangcs-sa  namespace: default

而后新建一个 Role 对象：(wangcs-sa-role.yaml)

apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:  name: wangcs-sa-role  namespace: defaultrules:- apiGroups: [""]  resources: ["pods"]  verbs: ["get", "watch", "list"]- apiGroups: ["apps"]  resources: ["deployments"]  verbs: ["get", "list", "watch"]

能够看到咱们这里定义的角色只有查问pod和deployment权限，待会咱们能够重点测试一下，创立该 Role 对象：

[root@k8s-master k8s-rbac]# kubectl apply -f wangcs-sa-role.yamlrole.rbac.authorization.k8s.io/wangcs-sa-role created

而后创立一个 RoleBinding 对象，将下面的 ServiceAccount wangcs-sa 和role wangcs-sa-role 进行绑定：(wangcs-sa-rolebinding.yaml)

kind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata:  name: wangcs-sa-rolebinding  namespace: defaultsubjects:- kind: ServiceAccount  name: wangcs-sa  namespace: defaultroleRef:  kind: Role  name: wangcs-sa-role  apiGroup: rbac.authorization.k8s.io

增加这个资源对象：

[root@k8s-master k8s-rbac]# kubectl apply -f wangcs-sa-rolebinding.yaml rolebinding.rbac.authorization.k8s.io/wangcs-sa-rolebinding created

测试

首先获取到ServiceAccount wangcs-sa对应的secret的token

[root@k8s-master ~]# kubectl get secret wangcs-sa-token-b6blc -o yamlapiVersion: v1data:  ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM1ekNDQWMrZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeE1EUXdOekV4TkRNek9Wb1hEVE14TURRd05URXhORE16T1Zvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBSlFWCjNmRmVraUdmL3ZDK1JPNFR4SC9QbkRhMmJINi9lRFAzNUc1SXppUnladmpUWWtNeGVyOHIrTWdndCtCN05oc28Ka0ZCVVNCVUhrbVhHZFFBUHRjNTJocVdGRlhtZk10TzBhNzZBTWNCdFZUa2hPZDRxc3NPcy9jUndVcGxYKytteApLcW9FdDc0eFBhRnJxRzIyeDVEN011Y3lYQmtxQk4vWGRKcThKNU5xTWhHd2EvbjVtbWUxYmRrdGh3UWd1SnZzCkc2THRBZGZhRWdXbWxnUVFUMWZHNkhVV3g0L085aTJSNEhIU1VXMDFmTnUwaGFVekNJcE04VERLMk9DbDJYN04KcWE3QitGZDlZR1krUVdhNWVMZk9nMFJUcTJOb210M1E5WWVGWHJKZDJMOHlpc3VsbjM0ZDNxZjFQakxtMkdJQwpQS01XenBVaWJxbkpNb0RvdjYwQ0F3RUFBYU5DTUVBd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZNeFh4azYydHVGSk1iTjNFTW03Q2M1RG5iMExNQTBHQ1NxR1NJYjMKRFFFQkN3VUFBNElCQVFBdW5WUXYvTnhnN2JCYXBiVWRVT2s4UWhkclZkbXFGVUlCWnlQN0FUMlh5eVNlMG8xVwp4dEU3c1NyWlQvZDJUTzJseFRLM0NQRVU2dW9uMDQ1amhyd1N1dGNVa3llMUZVcnF6aWNTa1luZjhnVFdOMmtlCnpUdWJ5OUowcVZFRVErc2cvU2Q1bERVUm9LSHAyVXRLZzdrbVRzT3d3U2ppVnlVZEdmMGcrZ2djUU9iMjFvNVgKYUtoOUtIQUdBVDRvQnlOdTY0STJEaWV0QkRkWWdsL3B5cTgwcCtwVTlLSDJObEZrMERhc01uU2I0eEE1M2U3RApJQVJua0JGOFNuSXR2a3pacFFTVWhXNVpJT2IvdjdOcWZxalhuTE8rdUx4czRPSllXL3V5TzBpMEkrYUF5RWRYClUyUkMzZjIyUHV1VmNnWmZ6ck5vUzU5dnQwVVlVM1FRcURqMgotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==  namespace: ZGVmYXVsdA==  token: ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNklraDZZMnB4VlhCbk5ubFBVa3AxVVZwblYwbGthMmhOZG14TVpHeHdOa1pGVFdvMVFXUkhjbUpPWldNaWZRLmV5SnBjM01pT2lKcmRXSmxjbTVsZEdWekwzTmxjblpwWTJWaFkyTnZkVzUwSWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXVZVzFsYzNCaFkyVWlPaUprWldaaGRXeDBJaXdpYTNWaVpYSnVaWFJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5elpXTnlaWFF1Ym1GdFpTSTZJbmRoYm1kamN5MXpZUzEwYjJ0bGJpMWlObUpzWXlJc0ltdDFZbVZ5Ym1WMFpYTXVhVzh2YzJWeWRtbGpaV0ZqWTI5MWJuUXZjMlZ5ZG1salpTMWhZMk52ZFc1MExtNWhiV1VpT2lKM1lXNW5ZM010YzJFaUxDSnJkV0psY201bGRHVnpMbWx2TDNObGNuWnBZMlZoWTJOdmRXNTBMM05sY25acFkyVXRZV05qYjNWdWRDNTFhV1FpT2lJNU9EZ3pPV1kxT0MweE5EZG1MVFEzWm1NdE9HVXlaQzFoTjJRMk1HRmtOakUyWVRNaUxDSnpkV0lpT2lKemVYTjBaVzA2YzJWeWRtbGpaV0ZqWTI5MWJuUTZaR1ZtWVhWc2REcDNZVzVuWTNNdGMyRWlmUS5BRl85T1hWd1pkeGVnckRSYWtXYjFrYWM3YmVlclBNTE03T2IwU3JiN2pPcFl4VzdMQllxNkpqNUE5NWxRQm9Yd3haQ09WLUtsYUZxSDc2RnZBRnFYX2taWE5XdWFkeElIZzhkWmVwWl9HbnJwYXBSeFFZZVlsbGRFR3BRdHZZSXdqLUsxRE9xMEprYnM3TW55dGUtcDE0WWxDWGZrdGp2NnVlaDEtcHZnRWRhbjdlS2xjNldwaFFvNnNRUm8xNmppc1VINkRvYU5FdXIxcGpXWVRHSlpuZ2tmQVU2QkNnV1lkRDd1MmwwZnV5dXh0Z2RyM0V1cHBmSVc1Wk5DQVBBbVU3SWRFd3JBVWJtWW5jZ3JyeTNaQWsxR1ctbnlpa0tWTmNNa29NTFAxejIwdHlQWUFaUkVHOTdSWkRhd1JQM1NvSXlIZTRxM245V1hhN0QxdjhSM1E=kind: Secret...

对token进行base64解密

echo -n "ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNklraDZZMnB4VlhCbk5ubFBVa3AxVVZwblYwbGthMmhOZG14TVpHeHdOa1pGVFdvMVFXUkhjbUpPWldNaWZRLmV5SnBjM01pT2lKcmRXSmxjbTVsZEdWekwzTmxjblpwWTJWaFkyTnZkVzUwSWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXVZVzFsYzNCaFkyVWlPaUprWldaaGRXeDBJaXdpYTNWaVpYSnVaWFJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5elpXTnlaWFF1Ym1GdFpTSTZJbmRoYm1kamN5MXpZUzEwYjJ0bGJpMWlObUpzWXlJc0ltdDFZbVZ5Ym1WMFpYTXVhVzh2YzJWeWRtbGpaV0ZqWTI5MWJuUXZjMlZ5ZG1salpTMWhZMk52ZFc1MExtNWhiV1VpT2lKM1lXNW5ZM010YzJFaUxDSnJkV0psY201bGRHVnpMbWx2TDNObGNuWnBZMlZoWTJOdmRXNTBMM05sY25acFkyVXRZV05qYjNWdWRDNTFhV1FpT2lJNU9EZ3pPV1kxT0MweE5EZG1MVFEzWm1NdE9HVXlaQzFoTjJRMk1HRmtOakUyWVRNaUxDSnpkV0lpT2lKemVYTjBaVzA2YzJWeWRtbGpaV0ZqWTI5MWJuUTZaR1ZtWVhWc2REcDNZVzVuWTNNdGMyRWlmUS5BRl85T1hWd1pkeGVnckRSYWtXYjFrYWM3YmVlclBNTE03T2IwU3JiN2pPcFl4VzdMQllxNkpqNUE5NWxRQm9Yd3haQ09WLUtsYUZxSDc2RnZBRnFYX2taWE5XdWFkeElIZzhkWmVwWl9HbnJwYXBSeFFZZVlsbGRFR3BRdHZZSXdqLUsxRE9xMEprYnM3TW55dGUtcDE0WWxDWGZrdGp2NnVlaDEtcHZnRWRhbjdlS2xjNldwaFFvNnNRUm8xNmppc1VINkRvYU5FdXIxcGpXWVRHSlpuZ2tmQVU2QkNnV1lkRDd1MmwwZnV5dXh0Z2RyM0V1cHBmSVc1Wk5DQVBBbVU3SWRFd3JBVWJtWW5jZ3JyeTNaQWsxR1ctbnlpa0tWTmNNa29NTFAxejIwdHlQWUFaUkVHOTdSWkRhd1JQM1NvSXlIZTRxM245V1hhN0QxdjhSM1E="|base64 -deyJhbGciOiJSUzI1NiIsImtpZCI6Ikh6Y2pxVXBnNnlPUkp1UVpnV0lka2hNdmxMZGxwNkZFTWo1QWRHcmJOZWMifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6Indhbmdjcy1zYS10b2tlbi1iNmJsYyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJ3YW5nY3Mtc2EiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiI5ODgzOWY1OC0xNDdmLTQ3ZmMtOGUyZC1hN2Q2MGFkNjE2YTMiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6ZGVmYXVsdDp3YW5nY3Mtc2EifQ.AF_9OXVwZdxegrDRakWb1kac7beerPMLM7Ob0Srb7jOpYxW7LBYq6Jj5A95lQBoXwxZCOV-KlaFqH76FvAFqX_kZXNWuadxIHg8dZepZ_GnrpapRxQYeYlldEGpQtvYIwj-K1DOq0Jkbs7Mnyte-p14YlCXfktjv6ueh1-pvgEdan7eKlc6WphQo6sQRo16jisUH6DoaNEur1pjWYTGJZngkfAU6BCgWYdD7u2l0fuyuxtgdr3EuppfIW5ZNCAPAmU7IdEwrAUbmYncgrry3ZAk1GW-nyikKVNcMkoMLP1z20tyPYAZREG97RZDawRP3SoIyHe4q3n9WXa7D1v8R3Q

接下来，应用这个token 对apiserver发动申请 https://{apiserver ip}:6443/api/v1/namespaces/default/pods

curl -k -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Ikh6Y2pxVXBnNnlPUkp1UVpnV0lka2hNdmxMZGxwNkZFTWo1QWRHcmJOZWMifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6Indhbmdjcy1zYS10b2tlbi1iNmJsYyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJ3YW5nY3Mtc2EiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiI5ODgzOWY1OC0xNDdmLTQ3ZmMtOGUyZC1hN2Q2MGFkNjE2YTMiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6ZGVmYXVsdDp3YW5nY3Mtc2EifQ.AF_9OXVwZdxegrDRakWb1kac7beerPMLM7Ob0Srb7jOpYxW7LBYq6Jj5A95lQBoXwxZCOV-KlaFqH76FvAFqX_kZXNWuadxIHg8dZepZ_GnrpapRxQYeYlldEGpQtvYIwj-K1DOq0Jkbs7Mnyte-p14YlCXfktjv6ueh1-pvgEdan7eKlc6WphQo6sQRo16jisUH6DoaNEur1pjWYTGJZngkfAU6BCgWYdD7u2l0fuyuxtgdr3EuppfIW5ZNCAPAmU7IdEwrAUbmYncgrry3ZAk1GW-nyikKVNcMkoMLP1z20tyPYAZREG97RZDawRP3SoIyHe4q3n9WXa7D1v8R3Q" "https://172.17.114.33:6443/api/v1/namespaces/default/pods"{  "kind": "PodList",  "apiVersion": "v1",  "metadata": {    "selfLink": "/api/v1/namespaces/default/pods",    "resourceVersion": "9141416"  },  "items": [    {      "metadata": {        "name": "nginx-deploy-75c7f965d8-hnmvn",        "generateName": "nginx-deploy-75c7f965d8-",        "namespace": "default",        "selfLink": "/api/v1/namespaces/default/pods/nginx-deploy-75c7f965d8-hnmvn",        "uid": "574ac979-41b8-460f-afaf-d29155911ba3",        "resourceVersion": "6786396",        "creationTimestamp": "2021-05-10T03:30:07Z",        "labels": {          "app": "nginx",          "pod-template-hash": "75c7f965d8"        },   ...

咱们看是能够拜访到default 命名空间的pod list，合乎预期
接下来，应用这个token 对apiserver发动申请 https://{apiserver ip}:6443/api/v1/namespaces/kube-system/pods，拜访kube-system命名空间下的pod list

[root@k8s-master ~]# curl -k -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Ikh6Y2pxVXBnNnlPUkp1UVpnV0lka2hNdmxMZGxwNkZFTWo1QWRHcmJOZWMifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6Indhbmdjcy1zYS10b2tlbi1iNmJsYyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJ3YW5nY3Mtc2EiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiI5ODgzOWY1OC0xNDdmLTQ3ZmMtOGUyZC1hN2Q2MGFkNjE2YTMiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6ZGVmYXVsdDp3YW5nY3Mtc2EifQ.AF_9OXVwZdxegrDRakWb1kac7beerPMLM7Ob0Srb7jOpYxW7LBYq6Jj5A95lQBoXwxZCOV-KlaFqH76FvAFqX_kZXNWuadxIHg8dZepZ_GnrpapRxQYeYlldEGpQtvYIwj-K1DOq0Jkbs7Mnyte-p14YlCXfktjv6ueh1-pvgEdan7eKlc6WphQo6sQRo16jisUH6DoaNEur1pjWYTGJZngkfAU6BCgWYdD7u2l0fuyuxtgdr3EuppfIW5ZNCAPAmU7IdEwrAUbmYncgrry3ZAk1GW-nyikKVNcMkoMLP1z20tyPYAZREG97RZDawRP3SoIyHe4q3n9WXa7D1v8R3Q" "https://172.17.114.33:6443/api/v1/namespaces/kube-system/pods"{  "kind": "Status",  "apiVersion": "v1",  "metadata": {      },  "status": "Failure",  "message": "pods is forbidden: User \"system:serviceaccount:default:wangcs-sa\" cannot list resource \"pods\" in API group \"\" in the namespace \"kube-system\"",  "reason": "Forbidden",  "details": {    "kind": "pods"  },  "code": 403}

返回403没有权限，合乎预期

能够全局拜访的 ServiceAccount

刚刚咱们创立的 wangcs-sa 这个 ServiceAccount 和一个 Role 角色进行绑定的，如果咱们当初创立一个新的 ServiceAccount，须要他操作的权限作用于所有的 namespace，这个时候咱们就须要应用到 ClusterRole 和 ClusterRoleBinding 这两种资源对象了。同样，首先新建一个 ServiceAcount 对象：(wangcs-sa2.yaml)

apiVersion: v1kind: ServiceAccountmetadata:  name: wangcs-sa2  namespace: default

创立：

[root@k8s-master k8s-rbac]# kubectl apply -f wangcs-sa2.yaml serviceaccount/wangcs-sa2 created

而后创立一个 ClusterRoleBinding 对象（wangcs-clusterolebinding.yaml）:

kind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1beta1metadata:  name: wangcs-sa2-clusterrolebindingsubjects:- kind: ServiceAccount  name: wangcs-sa2  namespace: defaultroleRef:  kind: ClusterRole  name: cluster-admin  apiGroup: rbac.authorization.k8s.io

从下面咱们能够看到咱们没有为这个资源对象申明 namespace，因为这是一个 ClusterRoleBinding 资源对象，是作用于整个集群的，咱们也没有独自新建一个 ClusterRole 对象，而是应用的 cluster-admin 这个对象，这是 Kubernetes 集群内置的 ClusterRole 对象，咱们能够应用 kubectl get clusterrole 和 kubectl get clusterrolebinding 查看零碎内置的一些集群角色和集群角色绑定，这里咱们应用的 cluster-admin 这个集群角色是领有最高权限的集群角色，所以个别须要审慎应用该集群角色。

创立：

kubectl apply -f wangcs-clusterolebinding.yaml Warning: rbac.authorization.k8s.io/v1beta1 ClusterRoleBinding is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 ClusterRoleBindingclusterrolebinding.rbac.authorization.k8s.io/wangcs-sa2-clusterrolebinding created

测试：

接下来，应用这个wangcs-sa2 对应的secret的token 对apiserver发动申请 https://{apiserver ip}:6443/api/v1/pods
!

[root@k8s-master k8s-rbac]# curl -k -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Ikh6Y2pxVXBnNnlPUkp1UVpnV0lka2hNdmxMZGxwNkZFTWo1QWRHcmJOZWMifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6Indhbmdjcy1zYTItdG9rZW4tdHQ1d2oiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoid2FuZ2NzLXNhMiIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjU3ZDU4M2JiLWMwNWUtNDU2NC04ZDQwLTIxOWJlMGM2NzBmMiIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0Ondhbmdjcy1zYTIifQ.YIYq33Ww8X8NNwjk_P-4IcV95e7j__aIv-2EX8AicsB_o2kwbfUvoe1Rgx8mN7MErRul46PgKshGL62C4D9pvZFi7H0BeFnY2CsUbYMIIHlEF_IhhKZLkXIbhgcQa8EzAa4KRkgcfO4ULPezO2EnLp-NPt4RABxaAa0aMbkYKgwL-ILCGKbNBQmrWASNcfgfjCavOZXW_hhyLIy_uO3PsCMP4k_T_Tv3lKOYzd8JnKLp1b1ytLrYBtinGYHgJHQB48XnNi8a-gL8rtp5GuDzOf_cQj43Fdub2yRtcNYgkLt6nAxlqNHV1ENjPxUYpJzqzsE5BWhcZQT6bZuyBlWobA" "https://172.17.114.33:6443/api/v1/pods"|more  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current                                 Dload  Upload   Total   Spent    Left  Speed  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0{  "kind": "PodList",  "apiVersion": "v1",  "metadata": {    "selfLink": "/api/v1/pods",    "resourceVersion": "9143830"  },  "items": [    {      "metadata": {        "name": "nginx-deploy-75c7f965d8-hnmvn",        "generateName": "nginx-deploy-75c7f965d8-",        "namespace": "default",        "selfLink": "/api/v1/namespaces/default/pods/nginx-deploy-75c7f965d8-hnmvn",        "uid": "574ac979-41b8-460f-afaf-d29155911ba3",        "resourceVersion": "6786396",        "creationTimestamp": "2021-05-10T03:30:07Z",        "labels": {          "app": "nginx",          "pod-template-hash": "75c7f965d8"        },  ...

所有命名空间下的pod list都可能查问进去，合乎预期

扫码加好友拉你入技术交换群，加微暗号：思否