二進制方式搭建k8s集群-(3)認證授權(quán)和服務發(fā)現(xiàn)

SourceURL:https://m.imooc.com/article/details?article_id=24677

1. 理解認證授權(quán)

1.1 為什么要認證

想理解認證，我們得從認證解決什么問題尽楔、防止什么問題的發(fā)生入手哺哼。
防止什么問題呢咬摇？是防止有人入侵你的集群疾瓮，root你的機器后讓我們集群依然安全嗎俺祠？不是吧瓦堵，root都到手了困鸥，那就為所欲為嗅蔬，防不勝防了。
其實網(wǎng)絡(luò)安全本身就是為了解決在某些假設(shè)成立的條件下如何防范的問題疾就。比如一個非常重要的假設(shè)就是兩個節(jié)點或者ip之間的通訊網(wǎng)絡(luò)是不可信任的澜术，可能會被第三方竊取，也可能會被第三方篡改猬腰。就像我們上學時候給心儀的女孩傳紙條鸟废，傳送的過程可能會被別的同學偷看，甚至內(nèi)容可能會從我喜歡你修改成我不喜歡你了姑荷。當然這種假設(shè)不是隨便想出來的盒延，而是從網(wǎng)絡(luò)技術(shù)現(xiàn)狀和實際發(fā)生的問題中發(fā)現(xiàn)、總結(jié)出來的鼠冕。kubernetes的認證也是從這個問題出發(fā)來實現(xiàn)的添寺。

1.2 概念梳理

為了解決上面說的問題，kubernetes并不需要自己想辦法懈费，畢竟是網(wǎng)絡(luò)安全層面的問題计露，是每個服務都會遇到的問題，業(yè)內(nèi)也有成熟的方案來解決憎乙。這里我們一起了解一下業(yè)內(nèi)方案和相關(guān)的概念票罐。

1.3 什么是授權(quán)

授權(quán)的概念就簡單多了乡数，就是什么人具有什么樣的權(quán)限，一般通過角色作為紐帶把他們組合在一起闻牡。也就是一個角色一邊擁有多種權(quán)限净赴，一邊擁有多個人。這樣就把人和權(quán)限建立了一個關(guān)系罩润。

2. kubernetes的認證授權(quán)

Kubernetes集群的所有操作基本上都是通過kube-apiserver這個組件進行的玖翅，它提供HTTP RESTful形式的API供集群內(nèi)外客戶端調(diào)用。需要注意的是：認證授權(quán)過程只存在HTTPS形式的API中割以。也就是說金度，如果客戶端使用HTTP連接到kube-apiserver，那么是不會進行認證授權(quán)的严沥。所以說猜极，可以這么設(shè)置，在集群內(nèi)部組件間通信使用HTTP消玄，集群外部就使用HTTPS跟伏，這樣既增加了安全性，也不至于太復雜翩瓜。
對APIServer的訪問要經(jīng)過的三個步驟受扳，前面兩個是認證和授權(quán)，第三個是 Admission Control兔跌，它也能在一定程度上提高安全性勘高，不過更多是資源管理方面的作用。

2.1 kubernetes的認證

kubernetes提供了多種認證方式坟桅，比如客戶端證書华望、靜態(tài)token、靜態(tài)密碼文件仅乓、ServiceAccountTokens等等赖舟。你可以同時使用一種或多種認證方式。只要通過任何一個都被認作是認證通過方灾。下面我們就認識幾個常見的認證方式建蹄。

  • 客戶端證書認證
    客戶端證書認證叫作TLS雙向認證，也就是服務器客戶端互相驗證證書的正確性裕偿，在都正確的情況下協(xié)調(diào)通信加密方案洞慎。
    為了使用這個方案，api-server需要用--client-ca-file選項來開啟嘿棘。
  • 引導Token
    當我們有非常多的node節(jié)點時劲腿，手動為每個node節(jié)點配置TLS認證比較麻煩，這時就可以用到引導token的認證方式鸟妙，前提是需要在api-server開啟 experimental-bootstrap-token-auth 特性焦人，客戶端的token信息與預先定義的token匹配認證通過后挥吵，自動為node頒發(fā)證書。當然引導token是一種機制花椭，可以用到各種場景中忽匈。
  • Service Account Tokens 認證
    有些情況下，我們希望在pod內(nèi)部訪問api-server矿辽，獲取集群的信息丹允，甚至對集群進行改動。針對這種情況袋倔，kubernetes提供了一種特殊的認證方式：Service Account雕蔽。 Service Account 和 pod、service宾娜、deployment 一樣是 kubernetes 集群中的一種資源批狐，用戶也可以創(chuàng)建自己的 Service Account。
    ServiceAccount 主要包含了三個內(nèi)容：namespace前塔、Token 和 CA嚣艇。namespace 指定了 pod 所在的 namespace，CA 用于驗證 apiserver 的證書嘱根，token 用作身份驗證髓废。它們都通過 mount 的方式保存在 pod 的文件系統(tǒng)中巷懈。

2.2 kubernetes的授權(quán)

在Kubernetes1.6版本中新增角色訪問控制機制（Role-Based Access该抒，RBAC）讓集群管理員可以針對特定使用者或服務賬號的角色，進行更精確的資源訪問控制顶燕。在RBAC中凑保，權(quán)限與角色相關(guān)聯(lián)，用戶通過成為適當角色的成員而得到這些角色的權(quán)限涌攻。這就極大地簡化了權(quán)限的管理欧引。在一個組織中，角色是為了完成各種工作而創(chuàng)造恳谎，用戶則依據(jù)它的責任和資格來被指派相應的角色芝此，用戶可以很容易地從一個角色被指派到另一個角色。
目前 Kubernetes 中有一系列的鑒權(quán)機制因痛，因為Kubernetes社區(qū)的投入和偏好婚苹，相對于其它鑒權(quán)機制而言，RBAC是更好的選擇鸵膏。具體RBAC是如何體現(xiàn)在kubernetes系統(tǒng)中的我們會在后面的部署中逐步的深入了解膊升。

2.3 kubernetes的AdmissionControl

AdmissionControl - 準入控制本質(zhì)上為一段準入代碼，在對kubernetes api的請求過程中谭企，順序為：先經(jīng)過認證 & 授權(quán)廓译，然后執(zhí)行準入操作评肆，最后對目標對象進行操作。這個準入代碼在api-server中非区，而且必須被編譯到二進制文件中才能被執(zhí)行瓜挽。
在對集群進行請求時，每個準入控制代碼都按照一定順序執(zhí)行征绸。如果有一個準入控制拒絕了此次請求秸抚，那么整個請求的結(jié)果將會立即返回，并提示用戶相應的error信息歹垫。
常用組件（控制代碼）如下：

  • AlwaysAdmit：允許所有請求
  • AlwaysDeny：禁止所有請求剥汤，多用于測試環(huán)境
  • ServiceAccount：它將serviceAccounts實現(xiàn)了自動化，它會輔助serviceAccount做一些事情排惨，比如如果pod沒有serviceAccount屬性吭敢，它會自動添加一個default，并確保pod的serviceAccount始終存在
  • LimitRanger：他會觀察所有的請求暮芭，確保沒有違反已經(jīng)定義好的約束條件鹿驼，這些條件定義在namespace中LimitRange對象中。如果在kubernetes中使用LimitRange對象辕宏，則必須使用這個插件畜晰。
  • NamespaceExists：它會觀察所有的請求，如果請求嘗試創(chuàng)建一個不存在的namespace瑞筐，則這個請求被拒絕凄鼻。

3. 環(huán)境準備

3.1 停止原有kubernetes相關(guān)服務

開始之前我們要先把基礎(chǔ)版本的集群停掉，包括service聚假，deployments块蚌，pods以及運行的所有kubernetes組件

#刪除services
$ kubectl delete services nginx-service

#刪除deployments
$ kubectl delete deploy kubernetes-bootcamp
$ kubectl delete deploy nginx-deployment

#停掉worker節(jié)點的服務
$ service kubelet stop && rm -fr /var/lib/kubelet/*
$ service kube-proxy stop && rm -fr /var/lib/kube-proxy/*
$ service kube-calico stop

#停掉master節(jié)點的服務
$ service kube-calico stop
$ service kube-scheduler stop
$ service kube-controller-manager stop
$ service kube-apiserver stop
$ service etcd stop && rm -fr /var/lib/etcd/*

3.2 生成配置（所有節(jié)點）

跟基礎(chǔ)環(huán)境搭建一樣，我們需要生成kubernetes-with-ca的所有相關(guān)配置文件

$ cd ~/kubernetes-starter
#按照配置文件的提示編輯好配置
$ vi config.properties
#生成配置
$ ./gen-config.sh with-ca

3.3 安裝cfssl（所有節(jié)點）

cfssl是非常好用的CA工具膘格，我們用它來生成證書和秘鑰文件
安裝過程比較簡單峭范，如下：

#下載
$ wget -q --show-progress --https-only --timestamping \
  https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 \
  https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
#修改為可執(zhí)行權(quán)限
$ chmod +x cfssl_linux-amd64 cfssljson_linux-amd64
#移動到bin目錄
$ mv cfssl_linux-amd64 /usr/local/bin/cfssl
$ mv cfssljson_linux-amd64 /usr/local/bin/cfssljson
#驗證
$ cfssl version

3.4 生成根證書（主節(jié)點）

根證書是證書信任鏈的根，各個組件通訊的前提是有一份大家都信任的證書（根證書）瘪贱，每個人使用的證書都是由這個根證書簽發(fā)的纱控。

#所有證書相關(guān)的東西都放在這
$ mkdir -p /etc/kubernetes/ca
#準備生成證書的配置文件
$ cp ~/kubernetes-starter/target/ca/ca-config.json /etc/kubernetes/ca
$ cp ~/kubernetes-starter/target/ca/ca-csr.json /etc/kubernetes/ca
#生成證書和秘鑰
$ cd /etc/kubernetes/ca
$ cfssl gencert -initca ca-csr.json | cfssljson -bare ca
#生成完成后會有以下文件（我們最終想要的就是ca-key.pem和ca.pem，一個秘鑰菜秦，一個證書）
$ ls
ca-config.json  ca.csr  ca-csr.json  ca-key.pem  ca.pem

4. 改造etcd

4.1 準備證書

etcd節(jié)點需要提供給其他服務訪問甜害，就要驗證其他服務的身份，所以需要一個標識自己監(jiān)聽服務的server證書喷户，當有多個etcd節(jié)點的時候也需要client證書與etcd集群其他節(jié)點交互唾那，當然也可以client和server使用同一個證書因為它們本質(zhì)上沒有區(qū)別。

#etcd證書放在這
$ mkdir -p /etc/kubernetes/ca/etcd
#準備etcd證書配置
$ cp ~/kubernetes-starter/target/ca/etcd/etcd-csr.json /etc/kubernetes/ca/etcd/
$ cd /etc/kubernetes/ca/etcd/
#使用根證書(ca.pem)簽發(fā)etcd證書
$ cfssl gencert \
        -ca=/etc/kubernetes/ca/ca.pem \
        -ca-key=/etc/kubernetes/ca/ca-key.pem \
        -config=/etc/kubernetes/ca/ca-config.json \
        -profile=kubernetes etcd-csr.json | cfssljson -bare etcd
#跟之前類似生成三個文件etcd.csr是個中間證書請求文件，我們最終要的是etcd-key.pem和etcd.pem
$ ls
etcd.csr  etcd-csr.json  etcd-key.pem  etcd.pem

4.2 改造etcd服務

建議大家先比較一下增加認證的etcd配置與原有配置的區(qū)別闹获，做到心中有數(shù)期犬。
可以使用命令比較：

$ cd ~/kubernetes-starter/
$ vimdiff kubernetes-simple/master-node/etcd.service kubernetes-with-ca/master-node/etcd.service

更新etcd服務：

$ cp ~/kubernetes-starter/target/master-node/etcd.service /lib/systemd/system/
#創(chuàng)建工作目錄(保存數(shù)據(jù)的地方)
$ mkdir -p /var/lib/etcd
$ systemctl daemon-reload
$ systemctl  enable  etcd.service
$ service etcd start
#驗證etcd服務（endpoints自行替換）
$ ETCDCTL_API=3 etcdctl \
  --endpoints=https://192.168.1.102:2379  \
  --cacert=/etc/kubernetes/ca/ca.pem \
  --cert=/etc/kubernetes/ca/etcd/etcd.pem \
  --key=/etc/kubernetes/ca/etcd/etcd-key.pem \
  endpoint health

5. 改造api-server

5.1 準備證書

#api-server證書放在這，api-server是核心避诽，文件夾叫kubernetes吧龟虎，如果想叫apiserver也可以，不過相關(guān)的地方都需要修改哦
$ mkdir -p /etc/kubernetes/ca/kubernetes
#準備apiserver證書配置
$ cp ~/kubernetes-starter/target/ca/kubernetes/kubernetes-csr.json /etc/kubernetes/ca/kubernetes/
$ cd /etc/kubernetes/ca/kubernetes/
#使用根證書(ca.pem)簽發(fā)kubernetes證書
$ cfssl gencert \
        -ca=/etc/kubernetes/ca/ca.pem \
        -ca-key=/etc/kubernetes/ca/ca-key.pem \
        -config=/etc/kubernetes/ca/ca-config.json \
        -profile=kubernetes kubernetes-csr.json | cfssljson -bare kubernetes
#跟之前類似生成三個文件kubernetes.csr是個中間證書請求文件沙庐，我們最終要的是kubernetes-key.pem和kubernetes.pem
$ ls
kubernetes.csr  kubernetes-csr.json  kubernetes-key.pem  kubernetes.pem

5.2 改造api-server服務

查看diff

$ cd ~/kubernetes-starter
$ vimdiff kubernetes-simple/master-node/kube-apiserver.service kubernetes-with-ca/master-node/kube-apiserver.service

生成token認證文件

#生成隨機token
$ head -c 16 /dev/urandom | od -An -t x | tr -d ' '
8afdf3c4eb7c74018452423c29433609

#按照固定格式寫入token.csv鲤妥，注意替換token內(nèi)容
$ echo "8afdf3c4eb7c74018452423c29433609,kubelet-bootstrap,10001,\"system:kubelet-bootstrap\"" > /etc/kubernetes/ca/kubernetes/token.csv

更新api-server服務

#在kube-apiserver.service文件中該行少一個true  ，--enable-bootstrap-token-auth=true
$ cp ~/kubernetes-starter/target/master-node/kube-apiserver.service /lib/systemd/system/
$ systemctl daemon-reload
$ systemctl  enable  kube-apiserver.service
$ service kube-apiserver start

#檢查日志
$ journalctl -f -u kube-apiserver

6. 改造controller-manager

controller-manager一般與api-server在同一臺機器上拱雏，所以可以使用非安全端口與api-server通訊棉安，不需要生成證書和私鑰。

6.1 改造controller-manager服務

查看diff

$ cd ~/kubernetes-starter/
$ vimdiff kubernetes-simple/master-node/kube-controller-manager.service kubernetes-with-ca/master-node/kube-controller-manager.service

更新controller-manager服務

$ cp ~/kubernetes-starter/target/master-node/kube-controller-manager.service /lib/systemd/system/
$ systemctl daemon-reload
$ systemctl  enable  kube-controller-manager.service
$ service kube-controller-manager start

#檢查日志
$ journalctl -f -u kube-controller-manager

7. 改造scheduler

scheduler一般與apiserver在同一臺機器上铸抑，所以可以使用非安全端口與apiserver通訊贡耽。不需要生成證書和私鑰。

7.1 改造scheduler服務

查看diff
比較會發(fā)現(xiàn)兩個文件并沒有區(qū)別鹊汛，不需要改造

$ cd ~/kubernetes-starter/
$ vimdiff kubernetes-simple/master-node/kube-scheduler.service kubernetes-with-ca/master-node/kube-scheduler.service

啟動服務

$ service kube-scheduler start
#檢查日志
$ journalctl -f -u kube-scheduler

8. 改造kubectl

8.1 準備證書

#kubectl證書放在這蒲赂，由于kubectl相當于系統(tǒng)管理員，我們使用admin命名
$ mkdir -p /etc/kubernetes/ca/admin
#準備admin證書配置 - kubectl只需客戶端證書刁憋，因此證書請求中 hosts 字段可以為空
$ cp ~/kubernetes-starter/target/ca/admin/admin-csr.json /etc/kubernetes/ca/admin/
$ cd /etc/kubernetes/ca/admin/
#使用根證書(ca.pem)簽發(fā)admin證書
$ cfssl gencert \
        -ca=/etc/kubernetes/ca/ca.pem \
        -ca-key=/etc/kubernetes/ca/ca-key.pem \
        -config=/etc/kubernetes/ca/ca-config.json \
        -profile=kubernetes admin-csr.json | cfssljson -bare admin
#我們最終要的是admin-key.pem和admin.pem
$ ls
admin.csr  admin-csr.json  admin-key.pem  admin.pem

8.2 配置kubectl

#指定apiserver的地址和證書位置（ip自行修改）
$ kubectl config set-cluster kubernetes \
        --certificate-authority=/etc/kubernetes/ca/ca.pem \
        --embed-certs=true \
        --server=https://192.168.1.102:6443
#設(shè)置客戶端認證參數(shù)滥嘴，指定admin證書和秘鑰
$ kubectl config set-credentials admin \
        --client-certificate=/etc/kubernetes/ca/admin/admin.pem \
        --embed-certs=true \
        --client-key=/etc/kubernetes/ca/admin/admin-key.pem
#關(guān)聯(lián)用戶和集群
$ kubectl config set-context kubernetes \
        --cluster=kubernetes --user=admin
#設(shè)置當前上下文
$ kubectl config use-context kubernetes

#設(shè)置結(jié)果就是一個配置文件，可以看看內(nèi)容
$ cat ~/.kube/config

驗證master節(jié)點

#可以使用剛配置好的kubectl查看一下組件狀態(tài)
$ kubectl get componentstatus
NAME                 STATUS    MESSAGE              ERROR
scheduler            Healthy   ok
controller-manager   Healthy   ok
etcd-0               Healthy   {"health": "true"}

9. 改造calico-node

9.1 準備證書

后續(xù)可以看到calico證書用在四個地方：

  • calico/node 這個docker 容器運行時訪問 etcd 使用證書

  • cni 配置文件中至耻，cni 插件需要訪問 etcd 使用證書

  • calicoctl 操作集群網(wǎng)絡(luò)時訪問 etcd 使用證書

  • calico/kube-controllers 同步集群網(wǎng)絡(luò)策略時訪問 etcd 使用證書

    #calico證書放在這
$ mkdir -p /etc/kubernetes/ca/calico
#準備calico證書配置 - calico只需客戶端證書若皱，因此證書請求中 hosts 字段可以為空
$ cp ~/kubernetes-starter/target/ca/calico/calico-csr.json /etc/kubernetes/ca/calico/
$ cd /etc/kubernetes/ca/calico/
#使用根證書(ca.pem)簽發(fā)calico證書
$ cfssl gencert \
    -ca=/etc/kubernetes/ca/ca.pem \
    -ca-key=/etc/kubernetes/ca/ca-key.pem \
    -config=/etc/kubernetes/ca/ca-config.json \
    -profile=kubernetes calico-csr.json | cfssljson -bare calico
#我們最終要的是calico-key.pem和calico.pem
$ ls
calico.csr  calico-csr.json  calico-key.pem  calico.pem

9.2 改造calico服務(所有節(jié)點都需要啟動)

查看diff

$ cd ~/kubernetes-starter
$ vimdiff kubernetes-simple/all-node/kube-calico.service kubernetes-with-ca/all-node/kube-calico.service

通過diff會發(fā)現(xiàn)，calico多了幾個認證相關(guān)的文件：
/etc/kubernetes/ca/ca.pem
/etc/kubernetes/ca/calico/calico.pem
/etc/kubernetes/ca/calico/calico-key.pem
由于calico服務是所有節(jié)點都需要啟動的有梆，大家需要把這幾個文件拷貝到每臺服務器上

更新calico服務

每個節(jié)點的 IP 都需要修改是尖，vim /lib/systemd/system/kube-calico.service 
里面有個-e IP="" 填的所在node的ip
$ cp ~/kubernetes-starter/target/all-node/kube-calico.service /lib/systemd/system/
$ systemctl daemon-reload
$ systemctl  enable  kube-calico.service
$ service kube-calico start

#驗證calico（能看到其他節(jié)點的列表就對啦）
$ calicoctl node status

10. 改造kubelet

我們這里讓kubelet使用引導token的方式認證意系，所以認證方式跟之前的組件不同泥耀，它的證書不是手動生成，而是由工作節(jié)點TLS BootStrap 向api-server請求蛔添，由主節(jié)點的controller-manager 自動簽發(fā)痰催。

10.1 創(chuàng)建角色綁定（主節(jié)點）

引導token的方式要求客戶端向api-server發(fā)起請求時告訴他你的用戶名和token，并且這個用戶是具有一個特定的角色：system:node-bootstrapper迎瞧，所以需要先將 bootstrap token 文件中的 kubelet-bootstrap 用戶賦予這個特定角色夸溶，然后 kubelet 才有權(quán)限發(fā)起創(chuàng)建認證請求。
在主節(jié)點執(zhí)行下面命令

#可以通過下面命令查詢clusterrole列表
$ kubectl -n kube-system get clusterrole

#可以回顧一下token文件的內(nèi)容
$ cat /etc/kubernetes/ca/kubernetes/token.csv
8afdf3c4eb7c74018452423c29433609,kubelet-bootstrap,10001,"system:kubelet-bootstrap"

#創(chuàng)建角色綁定（將用戶kubelet-bootstrap與角色system:node-bootstrapper綁定）
$ kubectl create clusterrolebinding kubelet-bootstrap \
         --clusterrole=system:node-bootstrapper --user=kubelet-bootstrap

10.2 創(chuàng)建bootstrap.kubeconfig（工作節(jié)點）

這個配置是用來完成bootstrap token認證的凶硅，保存了像用戶缝裁，token等重要的認證信息窿撬，這個文件可以借助kubectl命令生成：（也可以自己寫配置）

#設(shè)置集群參數(shù)(注意替換ip)
$ kubectl config set-cluster kubernetes \
        --certificate-authority=/etc/kubernetes/ca/ca.pem \
        --embed-certs=true \
        --server=https://192.168.1.102:6443 \
        --kubeconfig=bootstrap.kubeconfig
#設(shè)置客戶端認證參數(shù)(注意替換token)
$ kubectl config set-credentials kubelet-bootstrap \
        --token=8afdf3c4eb7c74018452423c29433609 \
        --kubeconfig=bootstrap.kubeconfig
#設(shè)置上下文
$ kubectl config set-context default \
        --cluster=kubernetes \
        --user=kubelet-bootstrap \
        --kubeconfig=bootstrap.kubeconfig
#選擇上下文
$ kubectl config use-context default --kubeconfig=bootstrap.kubeconfig
#將剛生成的文件移動到合適的位置
$ mv bootstrap.kubeconfig /etc/kubernetes/

10.3 準備cni配置（只用于工作節(jié)點 worker-node）

查看diff

$ cd ~/kubernetes-starter
$ vimdiff kubernetes-simple/worker-node/10-calico.conf kubernetes-with-ca/worker-node/10-calico.conf

copy配置

$ cp ~/kubernetes-starter/target/worker-node/10-calico.conf /etc/cni/net.d/

10.4 改造kubelet服務

查看diff

$ cd ~/kubernetes-starter
$ vimdiff kubernetes-simple/worker-node/kubelet.service kubernetes-with-ca/worker-node/kubelet.service

更新服務

kubelet.service 里面--address=172.16.5.208  --hostname-override，改成所在節(jié)點 ip
kubelet.kubeconfig 在啟動后會自動生成
bootstrap.kubeconfig和kubelet.kubeconfig都在kubelet.service有引用到

$ cp ~/kubernetes-starter/target/worker-node/kubelet.service /lib/systemd/system/
$ systemctl daemon-reload
$ systemctl  enable  kubelet.service
$ service kubelet start

#啟動kubelet之后到master節(jié)點允許worker加入(批準worker的tls證書請求)
#--------*在主節(jié)點執(zhí)行*---------
$ kubectl get csr|grep 'Pending' | awk '{print $1}'| xargs kubectl certificate approve
#-----------------------------

#檢查日志
$ journalctl -f -u kubelet

11. 改造kube-proxy

11.1 準備證書

#proxy證書放在這
$ mkdir -p /etc/kubernetes/ca/kube-proxy

#準備proxy證書配置 - proxy只需客戶端證書吼鱼，因此證書請求中 hosts 字段可以為空劫谅。
#CN 指定該證書的 User 為 system:kube-proxy，預定義的 ClusterRoleBinding system:node-proxy 將User system:kube-proxy 與 Role system:node-proxier 綁定粹污，授予了調(diào)用 kube-api-server proxy的相關(guān) API 的權(quán)限
$ cp ~/kubernetes-starter/target/ca/kube-proxy/kube-proxy-csr.json /etc/kubernetes/ca/kube-proxy/
$ cd /etc/kubernetes/ca/kube-proxy/

#使用根證書(ca.pem)簽發(fā)calico證書
$ cfssl gencert \
        -ca=/etc/kubernetes/ca/ca.pem \
        -ca-key=/etc/kubernetes/ca/ca-key.pem \
        -config=/etc/kubernetes/ca/ca-config.json \
        -profile=kubernetes kube-proxy-csr.json | cfssljson -bare kube-proxy
#我們最終要的是kube-proxy-key.pem和kube-proxy.pem
$ ls
kube-proxy.csr  kube-proxy-csr.json  kube-proxy-key.pem  kube-proxy.pem

11.2 生成kube-proxy.kubeconfig配置

#設(shè)置集群參數(shù)（注意替換ip）
$ kubectl config set-cluster kubernetes \
        --certificate-authority=/etc/kubernetes/ca/ca.pem \
        --embed-certs=true \
        --server=https://192.168.1.102:6443 \
        --kubeconfig=kube-proxy.kubeconfig
#置客戶端認證參數(shù)
$ kubectl config set-credentials kube-proxy \
        --client-certificate=/etc/kubernetes/ca/kube-proxy/kube-proxy.pem \
        --client-key=/etc/kubernetes/ca/kube-proxy/kube-proxy-key.pem \
        --embed-certs=true \
        --kubeconfig=kube-proxy.kubeconfig
#設(shè)置上下文參數(shù)
$ kubectl config set-context default \
        --cluster=kubernetes \
        --user=kube-proxy \
        --kubeconfig=kube-proxy.kubeconfig
#選擇上下文
$ kubectl config use-context default --kubeconfig=kube-proxy.kubeconfig
#移動到合適位置
$ mv kube-proxy.kubeconfig /etc/kubernetes/kube-proxy.kubeconfig

11.3 改造kube-proxy服務

查看diff

$ cd ~/kubernetes-starter
$ vimdiff kubernetes-simple/worker-node/kube-proxy.service kubernetes-with-ca/worker-node/kube-proxy.service

經(jīng)過diff你應該發(fā)現(xiàn)kube-proxy.service沒有變化

啟動服務

#如果之前的配置沒有了段多，可以重新復制一份過去
kube-proxy.service --bind-address= \--hostname-override 改成所在節(jié)點 ip

$ cp ~/kubernetes-starter/target/worker-node/kube-proxy.service /lib/systemd/system/
$ systemctl daemon-reload

#安裝依賴軟件
$ apt install conntrack

#啟動服務
$ service kube-proxy start
#查看日志
$ journalctl -f -u kube-proxy

12. 改造kube-dns

kube-dns有些特別，因為它本身是運行在kubernetes集群中壮吩，以kubernetes應用的形式運行进苍。所以它的認證授權(quán)方式跟之前的組件都不一樣。它需要用到service account認證和RBAC授權(quán)鸭叙。
service account認證：
每個service account都會自動生成自己的secret觉啊，用于包含一個ca，token和secret沈贝，用于跟api-server認證
RBAC授權(quán)：
權(quán)限柄延、角色和角色綁定都是kubernetes自動創(chuàng)建好的。我們只需要創(chuàng)建一個叫做kube-dns的 ServiceAccount即可缀程，官方現(xiàn)有的配置已經(jīng)把它包含進去了搜吧。

12.1 準備配置文件

我們在官方的基礎(chǔ)上添加的變量，生成適合我們集群的配置杨凑。直接copy就可以啦

$ cd ~/kubernetes-starter
$ vimdiff kubernetes-simple/services/kube-dns.yaml kubernetes-with-ca/services/kube-dns.yaml

大家可以看到diff只有一處滤奈，新的配置沒有設(shè)定api-server。不訪問api-server撩满，它是怎么知道每個服務的cluster ip和pod的endpoints的呢蜒程？這就是因為kubernetes在啟動每個服務service的時候會以環(huán)境變量的方式把所有服務的ip，端口等信息注入進來伺帘。

12.2 創(chuàng)建kube-dns

$ kubectl create -f ~/kubernetes-starter/target/services/kube-dns.yaml
#看看啟動是否成功
$ kubectl -n kube-system get pods

13. 再試牛刀

終于昭躺，安全版的kubernetes集群我們部署完成了。

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末伪嫁，一起剝皮案震驚了整個濱河市领炫，隨后出現(xiàn)的幾起案子，更是在濱河造成了極大的恐慌张咳，老刑警劉巖帝洪，帶你破解...
    沈念sama閱讀 210,914評論 6贊 490
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件，死亡現(xiàn)場離奇詭異脚猾，居然都是意外死亡葱峡，警方通過查閱死者的電腦和手機，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 89,935評論 2贊 383
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進店門龙助，熙熙樓的掌柜王于貴愁眉苦臉地迎上來砰奕，“玉大人，你說我怎么就攤上這事【” “怎么了常空？”我有些...
    開封第一講書人閱讀 156,531評論 0贊 345
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵，是天一觀的道長盖溺。 經(jīng)常有香客問我漓糙，道長，這世上最難降的妖魔是什么烘嘱？ 我笑而不...
    開封第一講書人閱讀 56,309評論 1贊 282
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任昆禽，我火速辦了婚禮，結(jié)果婚禮上蝇庭，老公的妹妹穿的比我還像新娘醉鳖。我一直安慰自己，他們只是感情好哮内，可當我...
    茶點故事閱讀 65,381評論 5贊 384
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布盗棵。 她就那樣靜靜地躺著，像睡著了一般北发。 火紅的嫁衣襯著肌膚如雪纹因。 梳的紋絲不亂的頭發(fā)上，一...
    開封第一講書人閱讀 49,730評論 1贊 289
  • 城市分裂傳說
    那天琳拨，我揣著相機與錄音瞭恰，去河邊找鬼。 笑死狱庇，一個胖子當著我的面吹牛惊畏，可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播密任，決...
    沈念sama閱讀 38,882評論 3贊 404
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼颜启，長吁一口氣：“原來是場噩夢啊……” “哼！你這毒婦竟也來了浪讳？” 一聲冷哼從身側(cè)響起缰盏，我...
    開封第一講書人閱讀 37,643評論 0贊 266
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤，失蹤者是張志新（化名）和其女友劉穎驻债，沒想到半個月后乳规，有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體，經(jīng)...
    沈念sama閱讀 44,095評論 1贊 303
  • ?護林員之死
    正文 獨居荒郊野嶺守林人離奇死亡合呐，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,448評論 2贊 325
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年，在試婚紗的時候發(fā)現(xiàn)自己被綠了笙以。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片淌实。...
    茶點故事閱讀 38,566評論 1贊 339
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖，靈堂內(nèi)的尸體忽然破棺而出拆祈，到底是詐尸還是另有隱情恨闪，我是刑警寧澤，帶...
    沈念sama閱讀 34,253評論 4贊 328
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布放坏，位于F島的核電站咙咽，受9級特大地震影響，放射性物質(zhì)發(fā)生泄漏淤年。R本人自食惡果不足惜钧敞，卻給世界環(huán)境...
    茶點故事閱讀 39,829評論 3贊 312
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望麸粮。 院中可真熱鬧溉苛，春花似錦、人聲如沸弄诲。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,715評論 0贊 21
  • 一樁弒父案，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽齐遵。三九已至寂玲，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間梗摇，已是汗流浹背敢茁。 一陣腳步聲響...
    開封第一講書人閱讀 31,945評論 1贊 264
  • 情欲美人皮
    我被黑心中介騙來泰國打工， 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留留美，地道東北人彰檬。 一個月前我還...
    沈念sama閱讀 46,248評論 2贊 360
  • 代替公主和親
    正文 我出身青樓，卻偏偏與公主長得像谎砾，于是被迫代替她去往敵國和親逢倍。 傳聞我的和親對象是個殘疾皇子，可洞房花燭夜當晚...
    茶點故事閱讀 43,440評論 2贊 348