演習 - Azure Kubernetes Services クラスターにポリシーを割り当てる
Azure Kubernetes Service (AKS) クラスターの Azure ポリシーとイニシアティブを構成する準備ができました。
このユニットでは、非準拠ポッドをデプロイし、信頼されたレジストリのみの使用を強制する Azure Policy を適用します。 次に、別の非準拠ポッドをデプロイして、ポリシーの効果を確認します。 トラブルシューティングの手順を学習し、ポッドが作成されていない理由を確認します。 さらに、Linux ベースのワークロードの Kubernetes クラスター ポッドのセキュリティで制限された標準イニシアチブに対してデプロイします。
Note
この演習は省略してもかまいません。 この演習を実行する場合は、始める前に Azure サブスクリプションを作成する必要があります。 Azure アカウントをお持ちでない場合、またはこの時点で作成しない場合は、提示されている情報を理解するため手順に目を通してください。
非準拠ポッドをクラスターにデプロイする
まず、Docker Hub からクラスターにイメージを直接デプロイします。 最初の手順は、クラスターにサインインすることです。
Cloud Shell で、AKS クラスターにサインインします。
az aks get-credentials -n videogamecluster -g videogamerg次のコードを実行して Docker Hub から simple-nginx ポッドを作成します。
cat <<EOF | kubectl apply -f - apiVersion: apps/v1 kind: Deployment metadata: name: simple-nginx labels: app: nginx spec: selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: simple-nginx image: docker.io/library/nginx:stable resources: requests: cpu: 100m memory: 100Mi limits: cpu: 120m memory: 120Mi ports: - containerPort: 80 EOF次のコードを実行して、デプロイを公開するサービスをデプロイします。
cat <<EOF | kubectl create -f - apiVersion: v1 kind: Service metadata: name: simple-nginx labels: app: nginx spec: type: LoadBalancer ports: - port: 80 selector: app: nginx EOFデプロイされたサービスの一覧を表示します。
kubectl get servicessimple-nginx サービスの External-IP をコピーし、ブラウザーに貼り付けて、サービスが想定どおりに実行されることを確認します。
外部 IP が
<pending>として表示されている場合は、コマンドを再実行します。 ワークロードにパブリック IP アドレスを割り当てるには時間がかかります。
AKS クラスターに Azure Policy を適用する
ポリシーが強制適用されていないクラスターにワークロードを正常にデプロイしました。 次は、クラスターにポリシーを追加し、それがどのように影響するかを確認できます。
ポリシーを割り当てる
クラスターで特定のレジストリのイメージのみが許可されるようにする必要があります。 新しいポリシー定義を作成し、それをスコープに割り当てる必要があります。 ここでこのスコープは、videogamerg リソース グループです。 ポリシーは Azure portal、Azure PowerShell、または Azure CLI から作成し、割り当てることができます。 この演習では、ポータルでポリシーを作成します。
次の手順に従って、Azure portal を使用してクラスターを管理する組み込みのポリシー定義を確認します。 ここでは、"許可されたイメージのみ" のポリシーを適用します。
Azure portal の [ポリシー] ページに移動します。
Azure Policy ページの左側のウィンドウで、 [定義] を選択します。
[カテゴリ] ドロップダウン リスト ボックスから、[すべて選択] を使用してフィルターをクリアし、[Kubernetes] を選択します。
Kubernetes クラスター コンテナーでは、許可されたイメージのみを使用する必要があるというポリシー定義を選択します。
割り当てを選択します。
[スコープ] を、作成した Kubernetes クラスターのリソース グループ (この例では videogamerg リソース グループ) に設定します。
[許可されているコンテナー イメージの正規表現] フィールドに以下のとおり入力し、[確認および作成] ボタンをクリックします
.+\.azurecr\.io/.+$
- [作成] ボタンを選択します。
新しいポリシーが有効になったので、[割り当て] を選択して割り当てられたポリシーを表示し、作成したポリシーの割り当てを選択できます。
ポリシーの割り当ては、次の図のようになります。 既定では、効果は拒否に設定されます。 つまり、クラスターにデプロイできるのは、Azure Container Registry でホストされているイメージのみです。
ポリシー イニシアチブを割り当てる
ポリシーが正常に割り当てられたので、ポリシーをテストする前に、イニシアチブを割り当てます。 Azure Policy イニシアチブは、特定の目標や目的を実現するためにグループ化された Azure Policy の定義またはルールのコレクションです。 Azure イニシアチブは、一連のポリシーを論理的にグループ化して単一の項目として扱うことで、ポリシーの管理を簡略化します。
イニシアチブは、ポリシーの割り当てと同じ方法で割り当てることができます。 これらの手順に従って、"Linux ベースのワークロードの Kubernetes クラスター ポッドのセキュリティで制限された標準" イニシアチブを割り当てます。
- Azure portal の [ポリシー] ページに戻ります。
- Azure Policy ページの左側のウィンドウで、 [定義] を選択します。
- [カテゴリ] ドロップダウン リスト ボックスから、[すべて選択] を使用してフィルターをクリアし、[Kubernetes] を選択します。
- Linux ベースのワークロードの Kubernetes クラスター ポッドのセキュリティで制限された標準イニシアチブ定義を選択します。 少し時間を取ってイニシアチブの一部であるさまざまなポリシーを確認してください。
- 画面の左上隅にある [割り当て] ボタンを選択します。
- [スコープ] を、作成した Kubernetes クラスターのリソース グループ (この例では videogamerg) に設定します。 前の手順と同様にフォームの残りの部分に入力し、[確認および作成] を選択します。
- [作成] ボタンを選択します。
ここでは、[ポリシー] をクリックし、[割り当て] を選択すると、ポリシーの割り当てが再び表示されます。 作成したポリシー割り当てをクリックすると、この例では、効果が [監査] に設定されたことが表示されます。
Azure ポリシーをテストする
制限ポリシーがクラスターに割り当てられたので、次はテストを実行してポリシーが機能するかどうかを確認できます。 これを実証するために、新しいデプロイを作成し、デプロイが機能するかどうかを確認します。 まず、新しい kubernetes マニフェスト ファイルを作成してデプロイします。
重要
ポリシーの割り当てが有効になるまで 30 分ほどかかる場合があります。 この遅延のため、以下の手順ではポリシーの検証が成功する可能性があり、デプロイは失敗しません。 このような場合は、もう少し待ってからデプロイを再試行してください。
次のコマンドを実行すると、ポリシー割り当てが有効かどうかを確認できます。
kubectl get ConstraintTemplates
次の出力のような結果が表示されます。 一覧に k8sazurecontainerallowedimages が表示されている場合は、ポリシーが有効であることがわかります。
k8sazureallowedcapabilities 40m
k8sazureallowedseccomp 20m
k8sazureallowedusersgroups 40m
k8sazureblockautomounttoken 40m
k8sazureblockdefault 40m
k8sazureblockhostnamespace 40m
k8sazurecontainerallowedimages 40m
k8sazurecontainerallowedports 40m
k8sazurecontainerlimits 40m
k8sazurecontainernoprivilege 40m
k8sazurecontainernoprivilegeescalation 40m
k8sazuredefenderblockvulnerableimages 40m
k8sazuredisallowedcapabilities 40m
k8sazureenforceapparmor 40m
k8sazurehostfilesystem 40m
k8sazurehostnetworkingports 40m
k8sazureingresshttpsonly 40m
k8sazurereadonlyrootfilesystem 40m
k8sazureserviceallowedports 40m
k8sazurevolumetypes 20m
次のコードを使用して、別の
nginxのデプロイとサービスを作成します。cat <<EOF | kubectl create -f - apiVersion: apps/v1 kind: Deployment metadata: name: second-simple-nginx labels: app: second-nginx spec: selector: matchLabels: app: second-nginx template: metadata: labels: app: second-nginx spec: containers: - name: second-simple-nginx image: docker.io/library/nginx:stable resources: requests: cpu: 100m memory: 100Mi limits: cpu: 120m memory: 120Mi ports: - containerPort: 80 EOFサービスの作成
cat <<EOF | kubectl create -f - apiVersion: v1 kind: Service metadata: name: second-simple-nginx labels: app: second-nginx spec: type: LoadBalancer ports: - port: 80 selector: app: second-nginx EOFこれで、ポッドが作成されたかどうかを確認できます。
kubectl get pods
次の出力では、デプロイが作成されている場合でも、ポッドは作成されていません。 作成したポリシーによって、デプロイがブロックされました。 ただし、ポリシーが割り当てられる前に作成されたポッドは停止されません。 また、ポリシーによってサービスの作成は妨げられませんでした。 ブラウザーで EXTERNAL-IP を開いてみると、応答が返されません。これはさらに、デプロイが成功しなかったことを示しています。
NAME READY STATUS RESTARTS AGE
simple-nginx-66d884c498-msbpc 1/1 Running 0 63m
ポッドがデプロイされなかった理由を診断する
前のセクションでは、2 つ目のポッドがデプロイされていないことが判明しました。 このセクションでは、コマンド ラインを使用して理由を診断します。
まず、デプロイについて確認しましょう。 ReplicaSet は作成されたが、レプリカの作成は失敗したようです。
kubectl get replicasets次の例のような出力が得られるはずです。
NAME DESIRED CURRENT READY AGE second-simple-nginx-64969b4566 1 0 0 8m45s simple-nginx-66d884c498 1 1 1 72m次に、失敗した ReplicaSet について確認します。
second-simple-nginxで始まる ReplicaSet の名前をコピーし、その値を使用して次のコマンドを更新し、コマンドを実行します。kubectl describe replicaset <ReplicaSet name>コマンドの出力には、ポリシーのためにレプリカが失敗したことが示されています。
Warning FailedCreate 3m9s (x18 over 14m) replicaset-controller Error creating: admission webhook "validation.gatekeeper.sh" denied the request: [azurepolicy-container-allowed-images-bcfbd5e1e78f7c8b4104] Container image docker.io/library/nginx:stable for container second-simple-nginx has not been allowed.
デプロイを削除して、次の手順のために準備します。
kubectl delete deployment second-simple-nginx
Azure Container Registry イメージを使用してポッドを再デプロイする
これで、ポリシーによって、作成したポリシーに基づくクラスター内に Docker ハブからのイメージが作成されることが防止されるのがわかります。 Azure Container Registry (ACR) のイメージを使用して、同じワークロードを再デプロイしてみます。 このセクションでは、Azure Container Registry を作成します。 次に、Docker ハブから新しいレジストリに nginx イメージをコピーし、コンテナー レジストリからポッドの再デプロイを試みます。 Azure CLI を使用してコンテナー レジストリを作成します。
Azure portal で Cloud Shell に戻り、次のコマンドを入力して新しいコンテナー レジストリを作成します。
ACR_NAME=videogameacr$RANDOM az acr create --name $ACR_NAME \ --resource-group videogamerg \ --sku PremiumDocker Hub から新しいコンテナー レジストリにイメージをインポートします。
az acr import --name $ACR_NAME --source docker.io/library/nginx:stable --image nginx:v1イメージがインポートされたことを確認します。 結果の一覧に nginx が表示されます。
az acr repository list --name $ACR_NAME作成したコンテナー レジストリに AKS クラスターをリンクします。
az aks update -n videogamecluster -g videogamerg --attach-acr $ACR_NAME次のコマンドを実行して、新しく作成したコンテナー レジストリを使用してデプロイを再作成します。
cat <<EOF | kubectl apply -f - apiVersion: apps/v1 kind: Deployment metadata: name: second-simple-nginx labels: app: second-nginx spec: selector: matchLabels: app: second-nginx template: metadata: labels: app: second-nginx spec: containers: - name: second-simple-nginx image: ${ACR_NAME}.azurecr.io/nginx:v1 resources: requests: cpu: 100m memory: 100Mi limits: cpu: 120m memory: 120Mi ports: - containerPort: 80 EOFクラスターでサービスが実行されていることをテストできるように、EXTERNAL-IP を取得します。
kubectl get pods kubectl get services
外部 IP アドレスをコピーし、ブラウザーに貼り付けます。 ページが読み込まれることがわかります。
ポリシーを使用して基準を適用する
このユニットでは、ポリシーを使用してクラスターで Azure Container Registry からのイメージのみの作成が許可されるようにする方法を見てきました。 また、クラスターを簡単に管理し、セキュリティを強化するのに役立つ組み込みイニシアチブの 1 つを追加する方法も確認しました。 ただし、ポリシーが割り当てられる前にデプロイされたポッドは引き続き実行されていることがわかりました。 次のユニットでは、クラスターで実行されているポッドのコンプライアンスを確認する方法について学習します。