K8Sクラスターをバイナリで構築する前に、最も退屈な点であるさまざまな証明書を整理する必要があります。
公式ドキュメントリファレンス：https：//kubernetes.io/docs/setup/certificates/
合計でいくつの証明書がありますか：
最初にEtcdから計算します。
1. Etcdは外部の関係者にサービスを提供し、etcdサーバー証明書のセットを必要とします
2. Etcdノード間で通信するには、etcdピア証明書のセットが必要です。
3. Kube-APIserverには、Etcdにアクセスするためのetcdクライアント証明書のセットが必要です。
次に、kubernetesを数えます。
4. Kube-APIserverは外部からサービスを提供し、kube-apiserverサーバー証明書のセットが必要です
5. kube-scheduler、kube-controller-manager、kube-proxy、kubelet、および使用される可能性のあるその他のコンポーネントは、kube-APIserverおよび一連のkube-APIserverクライアント証明書にアクセスする必要があります。
6、kube-controller-managerはサービスのサービスアカウントを生成したいと考えており、サービスアカウントの署名に使用される証明書のペア（CA証明書）が必要です。
7. kubeletが外部にサービスを提供する場合、kubeletサーバー証明書のセットが必要です
8. kube-APIserverはkubeletにアクセスする必要があり、kubeletクライアント証明書のセットが必要です
全部で8セットありますが、ここで「セット」の意味を理解する必要があります。
同じセットの証明書は同じCAによって署名されている必要があり、異なるセットの証明書に署名するCAは同じでも異なっていてもかまいません。たとえば、すべてのetcdサーバー証明書は同じCAによって署名される必要があり、すべてのetcdピア証明書も同じCAによって署名される必要があります。etcdサーバー証明書とetcdピア証明書は2つのCA機関によって署名できます。関連なし。これは、2セットの証明書としてカウントされます。
同じ「セット」内の証明書が同じCAによって署名されなければならない理由
その理由は、これらの証明書の検証にあります。最後にこれらの証明書を検証するため、通常は1つのルートCAしか指定できません。このように、検証する証明書は、当然、同じルートCAに対応する秘密鍵で署名する必要があります。そうしないと、認証に合格できません。
実際、K8Sは一連の証明書（すべて一連のCAによって署名されている）を使用して構築でき、本番環境にも使用できますが、これらの証明書間の関係が明確になり、証明書エラーのために要求が拒否された場合、起動することは不可能ではなく、証明書間の関係が理解されていない場合、問題を維持または解決するときに証明書が急いで置き換えられ、システム全体が麻痺する原因になります。
TLSブートストラップにより、kubelet証明書の作成が簡素化されます
Kubernetes 1.4バージョンでは、証明書に署名するための一連のAPIが導入されました。このAPIセットの導入により、kubeletが使用する証明書を事前に準備する必要がなくなりました。
公式ウェブサイトアドレス：https：//kubernetes.io/docs/tasks/tls/certificate-rotation/
各kubeletが使用する証明書は、独自のIPアドレスをバインドする必要があるため、一意であるため、kubeletごとに個別の証明書を作成する必要があります。ビジネスボリュームが大きい場合は、ノードノードが多くなるため、kubeletの数kubeletも増えており、kubeletの証明書作成は非常に面倒なこととなっています。TLSブートストラップを使用すると、多くの問題を回避できます。
仕組み： Kubeletを初めて起動すると、同じブートストラップトークンが資格情報として使用されます。このトークンは、ユーザーグループシステムであるbootstrappersに属するように事前に設定されており、このユーザーグループのアクセス許可も、証明書にのみ適用されるように制限されています。このブートストラップトークンで認証に合格した後、kubeletは独自の2セットの証明書（kubeletサーバー、kubeletのkube-apiserverクライアント）を申請します。申請が成功すると、独自の証明書を認証に使用するため、kubeletの正当な権限が与えられます。 。このようにして、各kubeletの証明書を手動で準備するプロセスが削除され、kubelet証明書をローテーションで自動的に更新することもできます。
参照文書：
https://mritd.me/2018/01/07/kubernetes-tls-bootstrapping-note/
https://www.jianshu.com/p/bb973ab1029b
kubelet証明書が異なるのはなぜですか
これは、セキュリティのために1つの監査ともう1つの監査に対して行われます。各kubeletはサーバー（kube-apiserverがkubeletにアクセスする必要がある）とクライアント（kubeletがkube-apiserverにアクセスする必要がある）の両方であるため、サーバー証明書とクライアント証明書の2つのセットが必要です。
サーバー証明書はサーバーアドレスにバインドする必要があります。各kubeletのアドレスは異なります。ドメイン名がバインドされていても、異なるドメイン名にバインドされているため、サーバーアドレスが異なります。
クライアント証明書は同じであってはなりません。各kubeletの認証証明書がそれが配置されているマシンのIPにバインドされた後、kubeletの認証証明書が漏洩するのを防ぎ、別のマシンからの偽造された要求が検証に合格できるようにします。
セキュリティの観点から、証明書の署名に使用されるブートストラップトークンが各ノードで予約されている場合、ブートストラップトークンがリークされた後、証明書に自由に署名することは可能ですか？安全上の問題は非常に大きいです。したがって、kubeletが正常に開始された後、ローカルブートストラップトークンを削除する必要があります。
公式生産証明書
複数の証明書セットを使用できますが、複数のCAセットを維持するには複雑すぎます。ここでは、1つのCAを使用してすべての証明書に署名します。
準備する証明書：
- admin.pem
- ca.-key.pem
- ca.pem
- admin-key.pem
- admin.pem
- kube-scheduler-key.pem
- kube-scheduler.pem
- kube-controller-manager-key.pem
- kube-controller-manager.pem
-
kube-proxy-key.pem
-
kube-proxy.pem
-
kubernetes-key.pem
-
kubernetes.pem
証明書を使用するコンポーネントは次のとおりです。
-
etcd：使用ca.pem kubernetes-key.pem kubernetes.pem
-
kube-apiserver使用使用ca.pemca-key.pem kubernetes-key.pem kubernetes.pem
-
kubelet：ca.pemを使用
-
kube-proxy：使用ca.pem kube-proxy-key.pem kube-proxy.pem
-
kubectl ca.pem admin-key.pem、admin.pem
-
kube-controller-manager：使用ca-key.pem ca.pem kube-controller-manager-key.pem kube-controller-manager.pem
- kube-scheduler：使用kube-scheduler-key.pem kube-scheduler.pem
CFSSLを使用して証明書を作成します。これはcloudflareによって開発されたオープンソースのPKIツールです。証明書に署名して取り消すことができる完全なCAサービスシステムです。証明書のライフサイクル全体をカバーします。後で使用するのはコマンドラインのみです。ツール。
注：通常、K8Sの証明書は1回だけ作成する必要があります。将来クラスターに新しいノードを追加するときは、/ etc / kubernetes / sslディレクトリの証明書を新しいノードにコピーするだけです。
wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
wget https://pkg.cfssl.org/R1.2 / cfssl-certinfo_linux-AMD64
のchmod + X cfssl_linux-AMD64 cfssljson_linux-AMD64 cfssl-certinfo_linux-AMD64
MV cfssl_linux-AMD64は/ usr / local /ビン/ cfssl
MV cfssljson_linux-AMD64は/ usr / local /ビン/ cfssljson
MV cfssl-certinfo_linux-AMD64 / usr / bin / cfssl-certinfo
CA証明書を作成する
証明書プロファイルを作成する
vim ca-config.json
{{
「署名」：{
"デフォルト"： {
「有効期限」：「87600h」
}、
"プロファイル"：{
"Kubernetes"：{
「使用法」：[
「署名」、
「鍵暗号化」、
「サーバー認証」、
「クライアント認証」
]、
「有効期限」：「87600h」
}
}
}
}
フィールドの説明：
ca-config.json：複数のプロファイルを定義し、さまざまな有効期限、使用シナリオ、およびその他のパラメーターを指定できます。その後、証明書に署名するときに特定のプロファイルを使用します。
署名：この証明書が他の証明書に署名できることを意味します;生成されたca.pem証明書のCA = TRUE;
server auth：クライアントがCAを使用して、サーバーから提供された証明書を検証できることを示します。
client auth：サーバーがCAを使用して、クライアントから提供された証明書を検証できることを示します。
有効期限：有効期限
CA証明書署名要求ファイルを作成します
vim ca-csr.json
{{
「CN」「kubernetes」
「キー」：{
"algo"： "rsa"、
「サイズ」：2048
}、
「名前」：[
{{
「C」：「CN」、
「ST」：「北京」、
「L」：「北京」、
「O」：「k8s」、
「OU」：「システム」
}
]、
"ca"：{
「有効期限」：「87600h」
}
}
フィールドの説明：
「CN」：共通名、kube-apiserverは、要求されたユーザー名（ユーザー名）として証明書からこのフィールドを抽出します。ブラウザーはこのフィールドを使用して、Webサイトが正当かどうかを確認します。
「O」：組織、kube-apiserverは、要求元のユーザーが属するグループとして、証明書からこのフィールドを抽出します
CA証明書と秘密鍵を生成する
cfssl gencert -initca ca-csr.json | cfssljson -bare ca
ls | grep ca
ca-config.json
ca.csr
ca-csr.json
ca-key.pem
ca.pem
その中で、ca-key.pemはcaの秘密鍵、ca.csrは署名要求、ca.pemはCA証明書であり、後でkubernetesコンポーネントによって使用されるRootCAです。
kubernetes証明書を作成する
この証明書を作成する前に、まずアーキテクチャを計画してください
k8s-master1 10.211.55.11
k8s-master2 10.211.55.12
k8s-master3 10.211.55.13
etcd01 10.211.55.11
etcd02 10.211.55.12
etcd03 10.211.55.13
VIP 10.211.55.8
kubernetes証明書署名要求ファイルを作成します
私はkubernetes-csr.jsonから来ました
{{
「CN」「kubernetes」
「ホスト」：[
「127.0.0.1」、
「10.211.55.11」、
「10.211.55.12」、
「10.211.55.13」、
「10.211.55.8」、
「10.0.0.1」、
「k8s-master1」、
「k8s-master2」、
「k8s-master3」、
「etcd01」、
「etcd02」、
「etcd03」、
「Kubernetes」
「kube-api.wangdong.com」、
"kubernetes.default"、
"kubernetes.default.svc"、
"kubernetes.default.svc.cluster"、
「kubernetes.default.svc.cluster.local」
]、
「キー」：{
"algo"： "rsa"、
「サイズ」：2048
}、
「名前」：[
{{
「C」：「CN」、
「ST」：「北京」、
「L」：「北京」、
「O」：「k8s」、
「OU」：「システム」
}
]
}
フィールドの説明：
ホストフィールドが空でない場合は、証明書の使用を許可されたIP名またはドメイン名のリストを指定する必要があります。
この証明書はその後、etcdクラスターとkubernetesマスタークラスターによって使用されるため、etcdノードとマスターノードのIP、およびサービスネットワークの最初のIPを入力します。（通常、これはkube-apiserverによって指定されたservice-cluster-ip-rangeネットワークセグメントの最初のIPです（10.0.0.1など））。
3つのetcd、3つのマスター、上記の物理ノードのIPもホスト名に置き換えることができます。
kubernetes証明書と秘密鍵を生成します
cfssl gencert -ca = ca.pem -ca-key = ca-key.pem -config = ca-config.json -profile = kubernetes kubernetes-csr.json | cfssljson -bare kubernetes
ls | grep kubernetes
kubernetes.csr
kubernetes-csr.json
kubernetes-key.pem
kubernetes.pem
管理者証明書を作成する
管理者証明書署名要求ファイルを作成します
vim admin-csr.json
{{
「CN」：「管理者」、
「ホスト」：[]、
「キー」：{
"algo"： "rsa"、
「サイズ」：2048
}、
「名前」：[
{{
「C」：「CN」、
「ST」：「北京」、
「L」：「北京」、
"O"： "system：masters"、
「OU」：「システム」
}
]
}
説明：
後続のkube-apiserverは、RBACを使用してクライアント（kubelet、kube-proxy、Podなど）の要求を承認します。
kube-apiserverは、RBACによって使用されるいくつかのRoleBindingを事前定義します。たとえば、cluster-adminはGroup system：mastersをRole cluster-adminにバインドします。このロールは、kube-apiserverのすべてのAPIを呼び出す権限を付与します。
Oは、証明書のグループをsystem：mastersとして指定します。kubeletが証明書を使用してkube-apiserverにアクセスすると、証明書はCAによって署名されるため、認証に合格します。同時に、証明書のユーザーグループが事前に存在するためです。承認されたシステム：マスター、すべてのAPI権限へのアクセスが許可されます。
注：この管理者証明書は、将来、管理者向けのkube構成構成ファイルを生成するために使用されます。現在はRBACを使用してkubernetesの役割と権限を制御することをお勧めします。Kubernetesは、証明書のCNフィールドをユーザーフィールドとOフィールドとして使用します。グループとして。
関連する権限認証については、次の記事を参照してください
https://mp.weixin.qq.com/s/XIkQdh5gnr-KJhuFHboNag
管理者証明書と秘密鍵を生成する
cfssl gencert -ca = ca.pem -ca-key = ca-key.pem -config = ca-config.json -profile = kubernetes admin-csr.json | cfssljson -bare admin
ls | grep管理者
admin.csr
admin-csr.json
admin-key.pem
admin.pem
kube-proxy証明書を作成する
kube-proxy証明書署名要求ファイルを作成します
vim kube-proxy-csr.json
{{
"CN"： "system：kube-proxy"、
「ホスト」：[]、
「キー」：{
"algo"： "rsa"、
「サイズ」：2048
}、
「名前」：[
{{
「C」：「CN」、
「ST」：「北京」、
「L」：「北京」、
「O」：「k8s」、
「OU」：「システム」
}
]
}
説明：
CNは、証明書のユーザーをsystem：kube-proxyとして指定します。
kube-apiserverの事前定義されたRoleBindingsystem：node-proxierは、ユーザーsystem：kube-proxyをRole system：node-proxierにバインドし、このロールはkube-apiserverProxy関連のAPIを呼び出す権限を付与します。
この証明書は、クライアント証明書としてkubectlによってのみ使用されるため、hostsフィールドは空です。
kube-proxy証明書と秘密鍵を生成する
cfssl gencert -ca = ca.pem -ca-key = ca-key.pem -config = ca-config.json -profile = kubernetes kube-proxy-csr.json | cfssljson -bare kube-proxy
ls | grep kube-proxy
kube-proxy.csr
kube-proxy-csr.json
kube-proxy-key.pem
kube-proxy.pem
kube-controoler-manager証明書を作成します
kube-controoler-manager証明書署名要求ファイルを作成します
vim kube-controller-manager-csr.json
{{
"CN"： "system：kube-controller-manager"、
「キー」：{
"algo"： "rsa"、
「サイズ」：2048
}、
「ホスト」：[
「127.0.0.1」、
「10.211.55.11」、
「10.211.55.12」、
「10.211.55.13」、
「k8s-master1」、
「k8s-master2」、
「k8s-master3」
]、
「名前」：[
{{
「C」：「CN」、
「ST」：「北京」、
「L」：「北京」、
"O"： "system：kube-controller-manager"、
「OU」：「システム」
}
]
}
説明：
ホストリストには、すべてのkube-controller-managerノードIPが含まれます。
CNはsystem：kube-controller-manager、Oはsystem：kube-controller-managerであり、kubernetesに組み込まれているClusterRoleBindings system：kube-controller-managerは、kube-controller-managerに必要な作業権限を与えます。
kube-controoller-manager証明書と秘密鍵を生成します
cfssl gencert -ca = ca.pem -ca-key = ca-key.pem -config = ca-config.json -profile = kubernetes kube-controller-manager-csr.json | cfssljson -bare kube-controller-manager
kube-scheduler証明書を作成する
kube-scheduler証明書署名要求ファイルを作成します
vim kube-scheduler-csr.json
{{
"CN"： "system：kube-scheduler"、
「ホスト」：[
「127.0.0.1」、
「10.211.55.11」、
「10.211.55.12」、
「10.211.55.13」、
「k8s-master1」、
「k8s-master2」、
「k8s-master3」、
]、
「キー」：{
"algo"： "rsa"、
「サイズ」：2048
}、
「名前」：[
{{
「C」：「CN」、
「ST」：「北京」、
「L」：「北京」、
「O」：「system：kube-scheduler」、
「OU」：「4Paradigm」
}
]
}
説明：
ホストリストには、すべてのkube-schedulerノードIPが含まれています。
CNはシステム：kube-scheduler、Oはシステム：kube-schedulerです。組み込みのClusterRoleBindingsシステム：kubernetesのkube-schedulerは、kube-schedulerに必要な作業権限を付与します。
上記の操作の後、以下のファイルを使用します
cfssl gencert -ca = ca.pem -ca-key = ca-key.pem -config = ca-config.json -profile = kubernetes kube-scheduler-csr.json | cfssljson -bare kube-scheduler
ls | grep pem
admin-key.pem
admin.pem
ca-key.pem
ca.pem
kube-proxy-key.pem
kube-proxy.pem
kubernetes-key.pem
kubernetes.pem
kube-controller-manager-key.pem
kube-controller-manager.pem
kube-scheduler-key.pem
kube-scheduler.pem
証明書情報の表示：
cfssl-certinfo -cert kubernetes.pem
k8sクラスターを構築するときは、これらのファイルをクラスター内の他のノードマシンに配布します。この時点で、TLS証明書が作成されます