kubernetes的Service Account和secret关系

https://blog.csdn.net/ccy19910925/article/details/80610336

Service Account

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

如果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就是字符串

echo "username" | base64

echo "password" | base64

apiVersion: v1
kind: Secret
metadata:
  name: mysecret-opaque
type: Opaque
data:
  username: d3Vibwo=
  password: amV0dGVjaAo=

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

apiVersion: v1
kind: Pod
metadata:
  #namespace: kube-system
  #namespace: default
  labels:
    name: busybox
    role: master
  name: busybox
spec:
  containers:
    - name: busybox
      image: docker.io/busybox
      command:
      - sleep
      - "360000"
      volumeMounts:
        - name: config-volume
          mountPath: /etc/config
          readOnly: true
  volumes:
    - name: config-volume
      secret:
        secretName: mysecret-opaque

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

apiVersion: v1
kind: Pod
metadata:
  #namespace: kube-system
  #namespace: default
  labels:
    name: busybox
    role: master
  name: busybox
spec:
  containers:
    - name: busybox
      image: docker.io/busybox
      command:
      - sleep
      - "360000"
      env:
        - name: SECRET_USERNAME
          valueFrom:
            secretKeyRef:
              name: mysecret-opaque
              key: username 
        - name: SECRET_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysecret-opaque
              key: password

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

imagePullSecrets

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

docker login 10.30.30.1:8123

 cat /root/.docker/config.json | base64 -w 0 生成编码

dockerconfigjson:生成编码

本次采坑就是在于编辑secret元素时type和date参数有变动，从k8s 1.8之后，kubernetes.io/dockercfg就变成kubernetes.io/dockerconfigjson，相对应 .dockercfg也变成.dockerconfigjson

iVersion: v1
kind: Secret
metadata:
  name: myregistrykey
  namespace: default
data:
  .dockerconfigjson: ewoJImF1dGhzIjogewoJCSIxMC4zMC4zMC4xOjgxMjMiOiB7CgkJCSJhdXRoIjogIllXUnRhVzQ2WVdSdGFXNHhNak09IgoJCX0KCX0KfQ==
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: default
spec:
  containers:
    - name: foo
      image: janedoe/awesomeapp:v1
  imagePullSecrets:
    - name: myregistrykey

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

其实本质上还是kubelet把这个认证放到了docker的目录下面，如下：
docker login 10.30.30.1:8123 就会生成如下内容
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=="
        }
    }
}

service-account-token

一： Service  Account

如果kubernetes开启了ServiceAccount（–admission_control=…,ServiceAccount,… ）那么会在每个namespace下面都会创建一个默认的default的ServiceAccount。位于/etc/kubernetes/apiserver的KUBE_ADMISSION_CONTROL="--admission-control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota“

 

每个ServiceAccount下面都会拥有一个加密过的secret作为Token. 该token也叫service-account-token，该token才是真正在API Server验证(authentication)环节起作用的。

 

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

查看一下secret的具体内容

上面的内容是经过base64加密过后的。可以看到ca.crt（这个是API Server的CA公钥证书，用于Pod中的Process对API Server的服务端数字证书进行校验时使用的）,namespace和token被放到了容器内，这样容器就可以通过https的请求访问apiserver了。

二 API Server的service account验证过程

 

以kube-system namespace下的“default” service account为例，Pod的usrname全称为：system:serviceaccount:kube-system:default。有了username，那么credentials呢？就是上面提到的service-account-token中的token。API Server的验证环节支持多种身份校验方式：CA 证书认证、Token 认证、Base 认证。一旦API Server发现client发起的request使用的是service account token的方式，API Server就会自动采用signed bearer token方式进行身份校验。而request就会使用携带的service account token参与验证。该token是API Server在创建service account时用API server启动参数：–service-account-key-file的值签署(sign)生成的。如果–service-account-key-file未传入任何值，那么将默认使用–tls-private-key-file的值，即API Server的私钥。

 

三：Secret

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

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

每个Namespace下有一个名为default的默认的Service Account对象，这个Service Account里面有一个名为Tokens的可以当作Volume一样被Mount到Podcast里的Secret,当Pod 启动时，这个Secret会自动被Mount到Pod的指定目录下，用来协助完成Pod中的进程访问API Server时的身份鉴权过程。

操作流程:

创建Service Account，会默认创建secret，然后pod中使用。也可以先创建secret然后创建Service Account在Service Account中使用自己创建的secret，然后pod中使用创建的Service Account