K8s -- 身份认证 Authentication

作者: 沉沦2014 | 来源:发表于2018-11-19 21:08 被阅读16次

1、Kubernetes中的用户

所有的系统都存在访问和使用其的用户，Kubernetes也一样，在Kubernetes集群中有存在两类用户：

serviceAccount（服务账号）：由Kubernetes进行管理的特殊用户，针对运行在Pods中运行的进程。
UserAccount（普通用户）：普通用户是由外部应用进行管理的用户，User Account针对人。

对于普通用户，Kubernetes管理员只负责为其分配私钥。普通用户可能来自于Keystone或google中，或者甚至是存储在文件中的用户名和密码列表。在Kubernetes中，没有表达普通用户的对象，因此，也就不能通过API将普通用户添加到集群中。

而Service Account是由Kubernetes API管理的用户，它们被绑定到特定的命名空间中，并由API服务器自动创建或通过API调用手动创建。Service Account与存储在Secrets的一组证书相关联，这些凭据被挂载到pod中，以允许集群中进程与Kubernetes API进行通信。

API请求要么来自于普通用户或Service Account，或来自于匿名请求。这就意味着集群内外部的所有进程（从来自于用户使用kubectl输入的请求，或来自于Nodes中kubelet的请求，或来自控制板的成员的请求）都需要进行认证才能与API server进行交互。。

2、UserAccount

下面是一个创建UserAccount并配置为kubectl的当前用户的实例，创建一个命名空间并在命名空间内创建用户和配置权限。

用户：wolken
组：test

第一步：创建命名空间test(在admin用户下)

kubectl create namespace test

第二步：创建用户凭证

在此利用openssl来创建，创建私钥，命名为wolken.key

openssl genrsa -out wolken.key 2048

使用刚刚创建的私钥创建证书请求签名wolken.csr，在-subj中指定用户和组

openssl req -new -key wolken.key -out wolken.csr -subj "/CN=wolken/O=test"

找到kubernetes集群认证中心，位置通常在/etc/kubernetes/pki，检查是否存在ca.crt、ca.key。生成最终的证书wolken.crt，有效期30天。

openssl x509 -req -in wolken.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out wolken.crt -days 30

到此凭证已经可用。可直接在kubeconfig中指定client-certificate与client-key文件位置。但是我需要在本地机器连接该账号。于是将wolken.crt与wolken.key转为base64。通过client-certificate-data与client-key-data配置。

cat wolken.crt|base64 --wrap=0
cat wolken.key|base64 --wrap=0

将输出写进kubeconfig，或者通过命令创建用户，将上面的输出替换对应位置{CRT_BASE64}与{KEY_BASE64}

kubectl config set-credentials wolken --client-certificate-data={CRT_BASE64}  --client-key-data={KEY_BASE64}

创建context（kubectl所连接的当前kubernetes集群、命名空间、以及当前UserAccount的上下文信息，详细信息请自行google关键词kubectl config）

kubectl config set-context wolken-context --cluster=kubernetes --namespace=test --user=wolken

利用该context尝试获取pod

kubectl --context=wolken-context get pod

会发现请求被forbidden，是因为没有配置权限给wolken。

第三步：创建Role

通过编排创建，编排文件：role.yml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: test
  name: role-hy
rules:
- apiGroups: ["","extensions","apps"]
  resources: ["pods"]
  verbs: ["get","watch","list"]

通过role.yml将创建一个role-hy，位于test命名空间，对pods资源有get、watch和list，其中api group：""表示core。

kubectl apply -f role.yml

第四步：创建RoleBindings

文件：role-bind.yml

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: rolebind-hy
  namespace: test
subjects:
- kind: User
  name: wolken
roleRef:
  kind: Role
  name: role-hy
  apiGroup: ""

kubectl apply -f role-bind.yml

重新get pod

kubectl --context=wolken-context get pod

可以发现已经可以获取在test命名空间的pod

3、ServiceAccount

Service Account概念的引入是基于这样的使用场景：运行在pod里的进程需要调用Kubernetes API以及非Kubernetes API的其它服务。Service Account它并不是给kubernetes集群的用户使用的，而是给pod里面的进程使用的，它为pod提供必要的身份认证。

kubectl get sa --all-namespaces

NAMESPACE     NAME          SECRETS   AGE
default       build-robot   1         1d
default       default       1         32d
default       kube-dns      1         31d
kube-public   default       1         32d
kube-system   dashboard     1         31d
kube-system   default       1         32d
kube-system   heapster      1         30d
kube-system   kube-dns      1         31d

如果kubernetes开启了ServiceAccount（–admission_control=…,ServiceAccount,… ）那么会在每个namespace下面都会创建一个默认的default的sa。
如下，其中最重要的就是secrets，它是每个sa下面都会拥有的一个加密的token，这个在下面的secret会详细介绍。

kubectl get sa  default  -o yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: 2017-05-02T06:39:12Z
  name: default
  namespace: default
  resourceVersion: "175"
  selfLink: /api/v1/namespaces/default/serviceaccounts/default
  uid: 0de23575-2f02-11e7-98d0-5254c4628ad9
secrets:
- name: default-token-rsf8r

当用户再该namespace下创建pod的时候都会默认使用这个sa，下面是get pod 截取的部分，可以看到kubernetes会把默认的sa挂载到容器内。

volumes:
  - name: default-token-rsf8r
    secret:
      defaultMode: 420
      secretName: default-token-rsf8r

具体看一下secret

kubectl get secret default-token-rsf8r -o yaml
apiVersion: v1
data:
  ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUR2akNDQXFhZ0F3SUJBZ0lVZlpvZDJtSzNsa3JiMzR3NDhhUmtOc0pVVDJjd0RRWUpLb1pJaHZjTkFRRUwKQlFBd1pURUxNQWtHQTFVRUJoTUNRMDR4RURBT0JnTlZCQWdUQjBKbGFVcHBibWN4RURBT0JnTlZCQWNUQjBKbAphVXBwYm1jeEREQUtCZ05WQkFvVEEyczRjekVQTUEwR0ExVUVDeE1HVTNsemRHVnRNUk13RVFZRFZRUURFd3ByCmRXSmxjbTVsZEdWek1CNFhEVEUzTURVd01qQTNNekF3TUZvWERUSXlNRFV3TVRBM016QXdNRm93WlRFTE1Ba0cKQTFVRUJoTUNRMDR4RURBT0JnTlZCQWdUQjBKbGFVcHBibWN4RURBT0JnTlZCQWNUQjBKbGFVcHBibWN4RERBSwpCZ05WQkFvVEEyczRjekVQTUEwR0ExVUVDeE1HVTNsemRHVnRNUk13RVFZRFZRUURFd3ByZFdKbGNtNWxkR1Z6Ck1JSUJJakFOQmdrcWhraUc5dzBCQVFFRkFBT0NBUThBTUlJQkNnS0NBUUVBc2E5Zk1HVGd2MGl0YnlZcHoycXkKOThKWktXdWdFL0VPbXRYS2ExT0Y3ekUxSFh1cDFOVG8rNkhvUEFuR3hhVzg4Q0s0TENrbWhNSGFLdUxnT3IvVApOMGphdnc5YWlPeVdYR1hXUUxVN3U0aVhoaDV6a2N4bmZxRW9JOW9JV2dMTzVEL3hBL0tnZzRQZDRMeFdqMkFQCk4rcVdxQ2crU3BrdkpIQUZWL3IyTk1BbEIzNHBrK0t5djVQMDJSQmd6Y2xTeSs5OUxDWnlIQ1VocGl0TFFabHoKdUNmeGtBeUNoWFcxMWNKdVFtaDM4aFVKa0dhUW9OVDVSNmtoRTArenJDVjVkWnNVMVZuR0FydWxaWXpJY3kregpkeUZpYWYyaitITyt5blg4RUNySzR1TUF3Nk4zN1pnNjRHZVRtbk5EWmVDTTlPelk5czBOVzc1dHU5bHJPZTVqCnZRSURBUUFCbzJZd1pEQU9CZ05WSFE4QkFmOEVCQU1DQVFZd0VnWURWUjBUQVFIL0JBZ3dCZ0VCL3dJQkFqQWQKQmdOVkhRNEVGZ1FVK2RqMThRUkZyMWhKMVhGb1VyYUVVRnpEeVRBd0h3WURWUjBqQkJnd0ZvQVUrZGoxOFFSRgpyMWhKMVhGb1VyYUVVRnpEeVRBd0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFBazQ4ODZBa0Fpa3VBVWRiOWU1CitldkVXVVFFaTIyTmc4REhmVTVSbXppU2ZhVllFQ1FuTlBUREprMmYvTm1Kb3RUVWxRZS9Ec3BkNEk1TFova1IKMGI2b1VoZkdmTkVOOXVObkkvZEgzOFBjUTNDaWtVeHhaeFRYTytaaldxcGNHZTRLNzZtaWd2ZWhQR2Z1VUNzQwp0UmZkZDM2YkhnRjN4MzRCWnc5MStDQ2VKQzBSWmNjVENqcHFHUEZFQlM3akJUVUlRVjNodnZycWJMV0hNeTJuCnFIck94UFI1eFkrRU5SQ0xzVWNSdk9icUhBK1g0c1BTdzBwMWpROXNtK1lWNG1ybW9Gd1RyS09kK2FqTVhzVXkKL3ZRYkRzNld4RWkxZ2ZvR3BxZFN6U1k0MS9IWHovMjZWNlFWazJBajdQd0FYZmszYk1wWHdDamRXRG4xODhNbQpXSHM9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
  namespace: ZGVmYXVsdA==
  token: ZXlKaGJHY2lPaUpTVXpJMU5pSXNJblI1Y0NJNklrcFhWQ0o5LmV5SnBjM01pT2lKcmRXSmxjbTVsZEdWekwzTmxjblpwWTJWaFkyTnZkVzUwSWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXVZVzFsYzNCaFkyVWlPaUprWldaaGRXeDBJaXdpYTNWaVpYSnVaWFJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5elpXTnlaWFF1Ym1GdFpTSTZJbVJsWm1GMWJIUXRkRzlyWlc0dGNuTm1PSElpTENKcmRXSmxjbTVsZEdWekxtbHZMM05sY25acFkyVmhZMk52ZFc1MEwzTmxjblpwWTJVdFlXTmpiM1Z1ZEM1dVlXMWxJam9pWkdWbVlYVnNkQ0lzSW10MVltVnlibVYwWlhNdWFXOHZjMlZ5ZG1salpXRmpZMjkxYm5RdmMyVnlkbWxqWlMxaFkyTnZkVzUwTG5WcFpDSTZJakJrWlRJek5UYzFMVEptTURJdE1URmxOeTA1T0dRd0xUVXlOVFJqTkRZeU9HRmtPU0lzSW5OMVlpSTZJbk41YzNSbGJUcHpaWEoyYVdObFlXTmpiM1Z1ZERwa1pXWmhkV3gwT21SbFptRjFiSFFpZlEuSmxuamM0Y0xNYkZrRlJVQjIyWGtFN2t4bTJ1dS1aQm9sUTh4VEdDNmdLOTdSZTVOMzBuY2V0SWJsanVOVWFlaDhtMDk2R19nMHE3cmRvWm5XMTV2OFBVXzNyM1hWWlBNc1lxbGRpZlNJbWtReXFqeEphVlBka3Izam5GWVBkVWNaTmk3MFF3cWtEdm5sMXB4SFRNZTZkTVNPTlExbUVoMHZSbHBhRTdjVWtTVlg5blRzaFVJVTVXWE9wRUxwdTVjVjBHV3ZGeDRDSzR6Umt3clNMdlV5X2d5UGZwLWdYVFZQWU80NkJKSWZtaVhlZGhVaW9nempPN285eGxDbUxQVkhyNkFIZGViNExiTVA1dkJ2MlBSZ2RrMW9keTR0VEdxLVRGU3M2VkNoMTZ4dk5IdTRtRVN5TjZmcXVObzJwYUFOelY4b251aTJuaU4yNTU1TzN4SFdR
kind: Secret
metadata:
  annotations:
    kubernetes.io/service-account.name: default
    kubernetes.io/service-account.uid: 0de23575-2f02-11e7-98d0-5254c4628ad9
  creationTimestamp: 2017-05-02T06:42:07Z
  name: default-token-rsf8r
  namespace: default
  resourceVersion: "12551"
  selfLink: /api/v1/namespaces/default/secrets/default-token-rsf8r
  uid: 75c0a236-2f02-11e7-98d0-5254c4628ad9
type: kubernetes.io/service-account-token

上面的内容是经过base64加密过后的，我们直接进入容器内：

~ # ls -l  /var/run/secrets/kubernetes.io/serviceaccount/
total 0
lrwxrwxrwx    1 root     root            13 May  4 23:57 ca.crt -> ..data/ca.crt
lrwxrwxrwx    1 root     root            16 May  4 23:57 namespace -> ..data/namespace
lrwxrwxrwx    1 root     root            12 May  4 23:57 token -> ..data/token

可以看到已将ca.crt 、namespace和token放到容器内了，那么这个容器就可以通过https的请求访问apiserver了。

Secret

Kubernetes提供了Secret来处理敏感信息，目前Secret的类型有3种：

Opaque(default): 任意字符串
kubernetes.io/service-account-token: 作用于ServiceAccount，就是上面说的。
kubernetes.io/dockercfg: 作用于Docker registry，用户下载docker镜像认证使用。

Opaque Secret

Opaque Secret就是字符串

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm

在使用的时候可以选择已volume方式或者是已环境变量的方式放到容器内使用。

{
 "apiVersion": "v1",
 "kind": "Pod",
  "metadata": {
    "name": "mypod",
    "namespace": "default"
  },
  "spec": {
    "containers": [{
      "name": "mypod",
      "image": "busybox",
      "command": ["sleep","3600"],
      "imagePullPolicy": "IfNotPresent",
      "volumeMounts": [{
        "name": "foo",
        "mountPath": "/etc/foo",
        "readOnly": true
      }]
    }],
    "volumes": [{
      "name": "foo",
      "secret": {
        "secretName": "mysecret"
      }
    }]
  }
}

这样就可以通过文件的方式挂载到容器内，在/etc/foo目录下回生成这个文件。
如果是环境变量当然也是ok的

apiVersion: v1
kind: Pod
metadata:
  name: secret-env-pod
spec:
  containers:
    - name: mycontainer
      image: busybox
      imagePullPolicy: IfNotPresent
      command:
        - sleep
        - "3600"
      env:
        - name: SECRET_USERNAME
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: username
        - name: SECRET_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: password

进入容器通过env命令，你将可以看到这两个环境变量被注入到容器内。

imagePullSecrets

当在需要安全验证的环境中拉取[镜像]的时候，需要通过用户名和密码。

apiVersion: v1
kind: Secret
metadata:
  name: myregistrykey
  namespace: awesomeapps
data:
  .dockerconfigjson: UmVhbGx5IHJlYWxseSByZWVlZWVlZWVlZWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGx5eXl5eXl5eXl5eXl5eXl5eXl5eSBsbGxsbGxsbGxsbGxsbG9vb29vb29vb29vb29vb29vb29vb29vb29vb25ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==
type: kubernetes.io/dockerconfigjson

或者直接通过命令创建

kubectl create secret docker-registry myregistrykey --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL

接下来拉取[镜像]的时候，就可以使用了

apiVersion: v1
kind: Pod
metadata:
  name: foo
  namespace: awesomeapps
spec:
  containers:
    - name: foo
      image: janedoe/awesomeapp:v1
  imagePullSecrets:
    - name: myregistrykey

其实本质上还是kubelet把这个认证放到了docker的目录下面，如下：

cat ~/.docker/config.json 
{
    "auths": {
        "10.39.0.118": {
            "auth": "Y2hlbm1vOmNtMTM4MTE2NjY3ODY="
        },
        "10.39.0.12:5000": {
            "auth": "dXNlcjAxOjEyMzQ1YQ=="
        },
        "http://10.39.0.12:5000": {
            "auth": "dXNlcjAxOjEyMzQ1YQ=="
        }
    }
}

K8s -- 身份认证 Authentication

1、Kubernetes中的用户

2、UserAccount

第一步：创建命名空间test(在admin用户下)

第二步：创建用户凭证

第三步：创建Role

第四步：创建RoleBindings

3、ServiceAccount

Secret

Opaque Secret

imagePullSecrets

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读