コンテナサービスTKEで動的アドミッションコントローラを使用する方法を教えます

原理の概要

動的アドミッションコントローラーWebhookは、アクセス認証プロセス中にリクエストオブジェクトを変更したり、リクエストを完全に拒否したりできます。Webhookサービスを呼び出す方法により、クラスターコンポーネントから独立しています。柔軟性が高く、簡単にカスタマイズできます。アクセス制御、次の図は、APIリクエストコールチェーンにおける動的アクセス制御の位置を示しています（Kubernetesの公式ウェブサイトから）。

上の図からわかるように、動的アドミッション制御プロセスは2つの段階に分かれています。最初に、到着要求を変更できる変更段階を実行し、次に検証段階を実行して、到着要求が許可されているかどうかを確認します。2つステージは個別に使用することも、組み合わせて使用することもできます。この記事では、TKEで簡単な動的アドミッション制御呼び出しの例を実装します。

検証プラグインを表示

TKEでは、既存のクラスターバージョン（1.10.5以降）がデフォルトで有効になっており、アドミッションWebhookを検証し、アドミッション番号WebHook APIを変更します。これがクラスターの以前のバージョンであり、Apiserver Podで実行できる場合kube-apiserver -h | grep enable-admission-pluginsは、現在のクラスターがオンになっていることを確認します。、出力プラグインリストが存在した場合MutatingAdmissionWebhookとValidatingAdmissionWebhook、以下に示すように、それは、現在のクラスタオープンアクセスプラグの動的制御を示します。

証明書を発行する

動的コールアドミッションコントローラーが信頼できるWebhookサーバーであり、HTTPSを介してWebhookサービス（TLS認証）と呼ばれるようにするには、Webhookサーバーの証明書を発行し、caBundleフィールド（ValidatingWebhookConfigurationおよび権限のMutatingAdmissionWebhookリソースリスト）に動的アクセス制御Webhookを登録する必要があります。caBundleWebhookサーバー証明書が信頼されていることを確認するために信頼された証明書（CA）フィールド）バインディング。ここでは、2つの推奨される証明書の方法を紹介しました。

注：サーバー証明書のドメイン名によって発行される（クラスター内のWebhookサービス）を構成するときValidatingWebhookConfigurationにMutatingAdmissionWebhook使用するclientConfig.service場合は、である必要があります<svc_name>.<svc_namespace>.svc。

方法1：自己署名証明書を作成する

自己署名証明書の作成方法は比較的独立しており、K8sクラスターに依存しません。Webサイトの自己署名証明書の作成に似ています。自己署名証明書を作成するためのツールは多数あります。この例では、自己署名証明書を作成するためのOpensslの手順は次のとおりです。

2048キービットでca.keyを生成します。
```
openssl genrsa -out ca.key 2048
```
ベースのca.keyは、-daysパラメーターを使用して証明書が有効な時間を設定し、クラスター内のWebhookドメインネームサーバーとしてca.crt「webserver.default.svc」を生成します。
```
openssl req -x509 -new -nodes -key ca.key -subj "/CN=webserver.default.svc" -days 10000 -out ca.crt
```

2048キービットでserver.keyを生成します。

openssl genrsa -out server.key 2048

i。証明書署名要求（CSR）を生成するための構成ファイルcsr.confを作成する例は次のとおりです。

[ req ]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn
[ dn ]
C = cn
ST = shaanxi
L = xi'an
O = default
OU = websever
CN = webserver.default.svc
[ v3_ext ]
authorityKeyIdentifier=keyid,issuer:always
basicConstraints=CA:FALSE
keyUsage=keyEncipherment,dataEncipherment
extendedKeyUsage=serverAuth,clientAuth

構成ファイルcsr.confに基づいて証明書署名要求を生成します。
```
openssl req -new -key server.key -out server.csr -config csr.conf
```

ca.key、ca.crt、およびserver.csrを使用して、サーバー証明書（x509署名）を発行および生成します。

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
 -CAcreateserial -out server.crt -days 10000 \
 -extensions v3_ext -extfile csr.conf

Webhookサーバー証明書の表示：

openssl x509  -noout -text -in ./server.crt

その中で、生成された証明書とキーファイルは次のように記述されます。

ca.crtは発行機関の証明書であり、ca.keyはサーバー側の証明書の発行に使用される発行機関の証明書キーです。

server.crtは発行されたサーバー証明書であり、server.keyは発行されたサーバー証明書キーです。

方法2：K8S CSRAPIを使用して発行する

暗号化ツールを使用して自己署名証明書を作成するだけでなく、k8sの認証局システムを使用して証明書を発行することもできます。次のスクリプトを実行すると、K8sクラスタールート証明書とルートキーを使用して信頼できる証明書ユーザーに署名できます。注そのユーザー名は、クラスター内のWebhookサービスのドメイン名である必要があります。

USERNAME='webserver.default.svc' # 设置需要创建的用户名为 Webhook 服务在集群中的域名
# 使用 Openssl 生成自签证书 key
openssl genrsa -out ${USERNAME}.key 2048
# 使用 Openssl 生成自签证书 CSR 文件, CN 代表用户名，O 代表组名
openssl req -new -key ${USERNAME}.key -out ${USERNAME}.csr -subj "/CN=${USERNAME}/O=${USERNAME}" 
# 创建 Kubernetes 证书签名请求（CSR）
cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1beta1
kind: CertificateSigningRequest
metadata:
  name: ${USERNAME}
spec:
  request: $(cat ${USERNAME}.csr | base64 | tr -d '\n')
  usages:
  - digital signature
  - key encipherment
  - server auth
EOF
# 证书审批允许信任
kubectl certificate approve ${USERNAME}
# 获取自签证书 CRT
kubectl get csr ${USERNAME} -o jsonpath={.status.certificate} > ${USERNAME}.crt

その中で、${USERNAME}.crtはサーバー証明書であり、${USERNAME}.keyはWebhookサーバー証明書キーです。

操作例

以下では、ValidatingWebhookConfigurationリソースを使用してTKEの例で動的な呼び出し許可Webhookを実現し、サンプルコードのサンプルコードを取得します（アクセシビリティを確保するために、ソースコードライブラリからのフォークサンプルコード、作成者は単純な動的アクセスWebhookを実装します要求と応答インターフェイスについては、特定のインターフェイス形式についてWebhookの要求と応答を参照してください。便宜上、これをWebhookサーバーコードとして使用します。

準備ができたcaBundleコンテンツ
- 証明書がプログラムによって発行された場合、base64エンコーディングca.crtで生成されたcaBundleフィールドの内容を使用します。
```
cat ca.crt | base64 --wrap=0
```
- オプションIIが証明書を発行する場合、ルート証明書クラスターはcaBundleフィールドのコンテンツであり、TKEクラスターをコンソールできます[基本情報]-> [情報]クラスターAPIServerKubeconfigコンテンツclusters.cluster[].certificate-authority-dataフィールドが取得され、フィールドはbase64エンコードされ、実行されなくなります処理。
生成されたca.crt（発行者証明書）、server.crt（HTTPS証明書））、server.key（HTTPSキー）をプロジェクトのメインディレクトリにコピーします。
プロジェクトのDockerfileを変更し、コンテナの作業ディレクトリに3つの証明書ファイルを追加します。

次に、dockerコマンドを使用してWebhookサーバーイメージを構築します。
```
docker build -t webserver .
```
ドメイン名「weserver.default.svc」でWebhookバックエンドサービスをデプロイし、適合したcontroller.yamlを次のように変更します。
サインアップしてValidatingWebhookConfigurationリソースのタイプを作成します。この例の構成ではpods、時間タイプを作成するとWebhookルールがトリガーされ、APIバージョン「v1」が呼び出しをトリガーclientConfigし、上記に対応するWebhookバックエンドサービスを構成します-クラスター内に作成されたcaBundleフィールドコンテンツは証明書を取得する方法です。ca.crtの内容は、以下に示すように、適応プロジェクトのadmission.yamlファイルを変更します。
登録後にポッドタイプを作成します。APIバージョン「v1」のテストリソースは次のとおりです。
テストコードには印刷要求ログがあります。Webhookサーバーログを確認すると、次の図に示すように、動的アドミッションコントローラーがWebhook呼び出しをトリガーしたことがわかります。
allowed: true次の図に示すように、テストWebhookサーバーコードは記述が難しいため、この時点で、作成されたテストポッドが正常に作成されていることを確認します。正常に作成できます。
さらに検証するために、「allowed」を「false」に変更してから、上記の手順を繰り返してWebサーバーサーバーのイメージを再作成し、controller.yamlリソースとadmission.yamlリソースを再デプロイします。「pods」リソースを再度作成しようとすると、リクエストは動的ですアドミッションインターセプトは、次の図に示すように、設定されたダイナミックアドミッションポリシーが有効であることを示します。