普通程序員看k8s的帳戶管理

1、知識準備

● 帳戶管理分爲：userAccount與serviceAccount
● userAccount：一般是給人設計使用的，而且userAccount不在k8s集羣內管理
● serviceAccount：一般是爲集羣內pod，外部service訪問而設計的，更輕量級，更專一與實現某個任務
● k8s帳戶管理，主要提供身份驗證的功能，必須是k8s受權的帳戶，才能被容許進入集羣。這裏須要注意的是身份驗證以後只是被容許進入集羣，可是不必定有訪問資源的權限，此時須要用到RBAC來實現
● k8s帳戶認證主要有證書+私鑰、token和帳戶名密碼等方式進行認證

2、環境準備

組件	版本
OS	Ubuntu 18.04.1 LTS
docker	18.06.0-ce
k8s	v1.10.1

3、userAccount

咱們首先生成一個userAccount，生成userAccount的方法：

建立mrvolleyball帳戶私鑰

root@k8s-master:/etc/kubernetes/ssl# openssl genrsa -out mrvolleyball.key 2048
Generating RSA private key, 2048 bit long modulus
.........+++
........................+++
e is 65537 (0x010001)

基於私鑰簽署證書，由k8s的ca來簽署（該ca是建立k8s集羣的時候生成的）

root@k8s-master:/etc/kubernetes/ssl# openssl req -new -key mrvolleyball.key -out mrvolleyball.csr -subj "/CN=mrvolleyball"
root@k8s-master:/etc/kubernetes/ssl# openssl x509 -req -in mrvolleyball.csr -CA k8s-root-ca.pem -CAkey k8s-root-ca-key.pem -CAcreateserial -out mrvolleyball.crt
Signature ok
subject=CN = mrvolleyball
Getting CA Private Key

注：k8s-root-ca.pem與k8s-root-ca-key.pem分別是證書與私鑰

簽署完成，k8s是怎麼識別你的帳戶名呢：

root@k8s-master:/etc/kubernetes/ssl# openssl x509 -in mrvolleyball.crt -text
Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number:
            e5:5e:0d:d2:bc:2e:8a:c6
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = CN, ST = ChengDu, L = ChengDu, O = k8s, OU = System, CN = kubernetes
        Validity
            Not Before: Mar  1 10:23:44 2019 GMT
            Not After : Mar 31 10:23:44 2019 GMT
        Subject: CN = mrvolleyball
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
...

k8s主要是經過Subject: CN = mrvolleyball來識別帳戶名

接下來將帳戶註冊到kubectl config當中進行管理：

root@k8s-master:/etc/kubernetes/ssl# kubectl config set-cluster mrvolleyball-k8s --server https://192.168.17.171:6443
Cluster "mrvolleyball-k8s" set.
root@k8s-master:/etc/kubernetes/ssl# kubectl config set-cluster mrvolleyball-k8s --certificate-authority=k8s-root-ca.pem
Cluster "mrvolleyball-k8s" set.
root@k8s-master:/etc/kubernetes/ssl# kubectl config set-context context@mrvolleyball-k8s --cluster=mrvolleyball-k8s --user=mrvolleyball
Context "context@mrvolleyball-k8s" created.
root@k8s-master:/etc/kubernetes/ssl# kubectl config set-credentials mrvolleyball --client-certificate=mrvolleyball.crt --client-key=mrvolleyball.key
User "mrvolleyball" set.

建立好以後使用新帳戶來登陸：

root@k8s-master:/etc/kubernetes/ssl# kubectl config use-context context@mrvolleyball-k8s
Switched to context "context@mrvolleyball-k8s".
root@k8s-master:/etc/kubernetes/ssl# kubectl get pod
Error from server (Forbidden): pods is forbidden: User "mrvolleyball" cannot list pods in the namespace "default"

因爲沒有權限，咱們只能容許被進入k8s集羣，可是沒有訪問任何資源的權限

4、serviceAccount

● 當一個pod被建立的時候，pod也須要去k8s-api註冊本身的信息，這時候使用的身份驗證及時serviceaccount
● 相對於建立證書與私鑰的方式，serviceaccount突出輕的特色，使用token認證

對於k8s來講，會默認在每個命名空間下面，建立一個token用於pod進行身份驗證

root@k8s-master:/etc/kubernetes/ssl# kubectl get secret --all-namespaces | grep default-token
default       default-token-v9nkm                        kubernetes.io/service-account-token   3         192d
kube-public   default-token-hzfqq                        kubernetes.io/service-account-token   3         192d
kube-system   default-token-g9ghd                        kubernetes.io/service-account-token   3         192d
test1         default-token-j5j67                        kubernetes.io/service-account-token   3         85d

當pod啓動的時候，會默認掛載當前namespace下secret進入pod，經過這個secret，進行身份驗證

建立一個busybox進行測試：

root@k8s-master:~# echo 'apiVersion: v1
> kind: Pod
> metadata:
>   name: busybox
> spec:
>   containers:
>   - image: busybox:latest
>     name: busybox
>     command: ["sleep","3600"]' | kubectl apply -f -
pod "busybox" created>

root@k8s-master:~# kubectl describe pod busybox
...
Volumes:
  default-token-v9nkm:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-v9nkm
    Optional:    false
...

來到volumes這裏，default-token-v9nkm正是咱們default namespace中默認的key，經過掛載這個secret，pod拿到了進入k8s-api的准入許可

5、小結

● 本文介紹了k8s的帳戶管理的兩種方式userAccount、serviceAccount，以及兩種不一樣的驗證方式
● 下一節介紹基於角色的權限控制RBAC

---

至此，本文結束 在下才疏學淺，有撒湯漏水的，請各位不吝賜教...