API Server作為Kubernetes網(wǎng)關千扔，是用戶訪問和管理資源對象的入口阔拳。每一次的訪問請求都需要對訪問者進行合法性的檢驗纱烘，包括身份驗證、資源操作權限驗證驗證等哗脖，通過一系列驗證通過之后才能返回訪問結果盾饮。
用戶可以通過kubectl命令, SDK，或者發(fā)送REST請求來訪問API 懒熙。User和Service Account是兩種不同用于訪問API的方式丘损。
User：
1，Kubernetes不直接管理用戶信息
2工扎，有外部獨立服務（LDAP徘钥，AD）進行管理的用戶，用戶不能通過集群內(nèi)部的 API 來進行管理
3肢娘， 用戶訪問API通過證書的方式進行認證
4呈础， k8s管理員和運維人員通過用戶的形式access kebernetes
ServiceAccount
1，服務賬號是通過Kubernetes API 來管理
2橱健，服務賬號適用于集群內(nèi)部運行的應用程序（pod）而钞，需要通過 API 來完成的操作
3，服務賬戶通過bearer token認證方式訪問API
RBAC授權
RBAC可以對user拘荡，group和serviceaccount進行API訪問權限控制臼节。Role和ClusterRole定義了權限集合，RoleBinding和ClusterRoleBinding用于將Role和ClusterRole上的許可權限綁定到一個珊皿，一組用戶或者一個服務賬號上网缝。
Role- 只能用于授予對某一單一命名空間中資源的訪問權限（rule是通過設定不同API group里的資源讀，寫蟋定，訂閱的權限）
ClusterRole- 可以授予與Role對象相同的權限粉臊，但由于它們屬于集群范圍對象， 也可以使用它們授予對以下幾種資源的訪問權限：
集群范圍資源（例如節(jié)點驶兜，即node）
非資源類型endpoint（例如”/healthz”）
跨所有命名空間的命名空間范圍資源（例如pod扼仲，需要運行命令kubectl get pods --all-namespaces來查詢集群中所有的pod）
RoleBinding- 可以引用在同一命名空間內(nèi)定義的Role對象远寸，在RoleBinding所在的命名空間內(nèi)授予用戶，組屠凶，服務賬戶對所引用的Role中 定義的命名空間資源的訪問權限
ClusterRoleBinding- 在集群級別和所有命名空間中授予用戶驰后，組，服務賬戶所綁定的ClusterRole資源權限阅畴。
實例1：添加一個新用戶并授予只讀權限
添加一個含有只讀權限的用戶通過kubectl訪問API server，首先需要創(chuàng)建一個X509的證書作為訪問API server的認證憑證迅耘，設置這個用戶的credentials和context贱枣，綁定此用戶到只讀權限的ClusterRole。利用這個用戶的context調(diào)用kubectl去操作k8s集群颤专。
1纽哥，利用cfssl這個工具生成證書，具體詳情搜索相關tool適用方法栖秕，這里只列出我個人生成的cert的命令和兩個配置文件sunfuqi.json春塌，ca-config.json
執(zhí)行命令，這里用到了kubernetes集群的CA證書來生成新用戶sunfuqi的客戶端證書簇捍。
/usr/local/bin/cfssl gencert --ca /etc/kubernetes/pki/ca.crt --ca-key /etc/kubernetes/pki/ca.key --config ca-config.json --profile=kubernetes sunfuqi.json | /usr/local/bin/cfssljson --bare readonly
命令執(zhí)行后會在所在目錄生成三個文件
利用文件2,3為kubectl添加crendential
kubectl config set-credentials sunfuqi --certificate-authority=/etc/kubernetes/pki/ca.crt --embed-certs=true --client-key=/root/users/sunfuqi/sunfuqi-key.pem --client-certificate=/root/users/sunfuqi/sunfuqi.pem
這條命令會在kubectl的配置文件里面添加一個sunfuqi的用戶只壳，并寫入證書的內(nèi)容
為這個用戶sunfuqi創(chuàng)建context，名字叫sunfuqi-context?
kubectl config set-context sunfuqi-context --user=sunfuqi --cluster=kubernetes
創(chuàng)建好后暑塑，通過kubectl命令查看吼句，新用戶的context，你也可以通過查看文件的形式去檢查配置文件($HOME/.kube/config)
kubectl config view
cat /root/.kube/config
kubernetes系統(tǒng)自帶一個readonly的cluster role名字叫做view事格，這里我就不再創(chuàng)建新的role惕艳，直接引用View ClusterRole和user sunfuqi綁定起來， 創(chuàng)建一個ClusterRoleBinding的配置文件, 并執(zhí)行
用戶和ClusterRole綁定后驹愚，我們就可以使用這個用戶去訪問API server來操作集群了远搪。
切換到sunfuqi-contxt這個上下文環(huán)境, 對集群做操作
可以看到通過sunfuqi這個用戶是可以list說有pod的，但是不能刪除逢捺，正好符合我們的預期谁鳍。創(chuàng)建一個新用戶并賦予只讀權限的例子就完成了。
實例2：創(chuàng)建一個service account實例
添加一個service account的用戶劫瞳，并授權這個用戶對services棠耕，pod，PV柠新， ingress等resource有增刪改查的權限窍荧， 創(chuàng)建一個deployment，pod利用這個service account去監(jiān)控service恨憎，如果有有新的service生成蕊退，把這個service加入到ingress的rules里面去郊楣，客戶可以通過ingress controller + 服務名 訪問服務。
創(chuàng)建一個Service Account瓤荔，取名resource-operator
創(chuàng)建好后净蚤，我們查看一下他的信息
可以看到有個Mountable secrets和Tokens的key，后面是引用的secret名字输硝， 這個secret是生成service account的時候自動生成的今瀑， 當一個create一個pod時指定resource-operator這個service account， k8s就會把這個secret mount到pod上的文件系統(tǒng)点把，pod里面的程序可以通過這個secret作為token訪問API server橘荠。 具體查看一下這個secret內(nèi)容
創(chuàng)建新的ClusterRole和ClusterRoleBinding
目前為止Service Account創(chuàng)建成功并和相應的Role綁定起來了。下面就是自己寫個程序放到容器里去驗證這個service account是否能正常訪問API server去操作集群郎逃。
我這個例子是用python寫的哥童，安裝了kubernetes的python 包，用來監(jiān)控集群的服務褒翰， 如果有新增的服務就會修改ingress配置贮懈， 為這個service配置一個rules。要實現(xiàn)這個目的优训， 我的集群上裝了一個ingress-controller（基于nginx）朵你，并配置了相應的ingress。
程序寫好打成docker image揣非， 具體程序內(nèi)容和打包過程撬呢，不再這里講述。
編寫deployment文件妆兑，并部署
這里設置了容器的serviceAccount 指向上面創(chuàng)建的服務賬戶魂拦，pod部署在指定的node上。
部署完成后查單pod的內(nèi)容搁嗓，正如前面所說這里我們可以看到service account的token被mount到pod指定目錄
去pod上查看一下指定目錄芯勘，發(fā)現(xiàn)里面有3個文件和上面secret的內(nèi)容一樣，pod里面的程序可以通過這個token去訪問API server腺逛。繼續(xù)查看pod的環(huán)境變量荷愕， 可以看到一些集群的信息以變量的形式提供給pod使用。
刪除一個service來驗證service account能夠準確操作集群棍矛。
刪除service httpd-svc前安疗， 有兩條paths在rule里面， 刪除httpd-svc 相應的path也被刪掉够委。至此以后不能通過/httpd-svc訪問服務荐类。這里也驗證了service account可以通過pod準確操作集群。
