Worker RAM ロールの権限を手動で制限してノードのセキュリティを向上させる - Container Service for Kubernetes

ACK マネージドクラスター内のノードのセキュリティを向上させるために、最小権限の原則に基づいてワーカーノードに割り当てられた RAM ロールの権限を手動で調整できます。

前提条件

バージョン 1.18 以降の ACK マネージドクラスター (ACK Managed Cluster Pro または ACK Managed Cluster Basic) が作成されていること。詳細については、「ACK マネージドクラスターの作成」および「クラスターの手動アップグレード」をご参照ください。
ACK 専用クラスターの権限を制限する場合は、ACK Managed Cluster Pro に移行してください。詳細については、「ACK 専用クラスターの ACK Managed Cluster Pro へのホットマイグレーション」をご参照ください。
ACK マネージドクラスターが必要とするデフォルトのサービスロールが付与されていること。詳細については、「ワンクリックでサービスロールに権限を付与する」をご参照ください。

ステップ 1: 制限が必要かどうかを確認する

ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、対象のクラスターの名前をクリックします。[基本情報] タブで、[ワーカー RAM ロール] の横にあるリンクをクリックして RAM コンソールを開きます。
[ロール] ページの [権限] タブで、アクセスポリシーが存在するかどうかを確認します。
- リストが空の場合、制限は必要ありません。
- リストが空でない場合、たとえば k8sWorkerRolePolicy-db8ad5c7*** が含まれている場合、Worker RAM ロールの権限を制限する必要がある場合があります。ビジネスシナリオと最小権限の原則に基づいて、続行するかどうかを判断できます。

ステップ 2: システムコンポーネントをアップグレードする

ACK マネージドクラスターにインストールされているコアシステムコンポーネントは、必要な最小バージョンまたは最新バージョンにアップグレードする必要があります。詳細については、「コンポーネントの管理」をご参照ください。

重要

複数のコンポーネントを同時にアップグレードしないでください。コンポーネントを 1 つずつアップグレードしてください。次のコンポーネントをアップグレードする前に、コンポーネントが正常にアップグレードされたことを確認してください。
コンポーネントをアップグレードする前に、コンポーネントの備考をお読みください。

コンポーネントは、コンポーネント管理またはノードプールを介して 2 つの方法でインストールされます。要件とアップグレード方法については、以下で説明します。

コンポーネント管理によってインストールされたコンポーネント

[コンポーネント管理] ページで、次の表を使用して、クラスターにインストールされているコンポーネントを必要な最小バージョンまたは最新バージョンにアップグレードします。アップグレードする必要のないコンポーネントについては、次の表の再デプロイコマンドを使用して再デプロイする必要があります。コンソールでコンポーネントを再デプロイすることもできます。

コンポーネント名	最小コンポーネントバージョン	コンポーネントを再デプロイするコマンド	備考
metrics-server	v0.3.9.4-ff225cd-aliyun	`kubectl -n kube-system rollout restart deployment/metrics-server`	なし
alicloud-monitor-controller	v1.5.5	`kubectl -n kube-system rollout restart deployment/alicloud-monitor-controller`	なし
logtail-ds	v1.0.29.1-0550501-aliyun	`kubectl -n kube-system rollout restart daemonset/logtail-ds kubectl -n kube-system rollout restart deployment/alibaba-log-controller`	なし
loongcollector	v3.0.2	`kubectl -n kube-system rollout restart daemonset/loongcollector-ds kubectl -n kube-system rollout restart deployment/loongcollector-operator`	なし
terway	v1.0.10.333-gfd2b7b8-aliyun	`kubectl -n kube-system rollout restart daemonset/terway`	インストールした Terway モードに基づいて、対応する Terway コンポーネントをアップグレードします。Terway モードの詳細については、「Terway ネットワークプラグインの使用」をご参照ください。コンポーネントをアップグレードした後、Terway コンポーネントの構成も手動で変更する必要があります。詳細については、「Terway コンポーネント構成の確認」をご参照ください。
terway-eni	v1.0.10.333-gfd2b7b8-aliyun	`kubectl -n kube-system rollout restart daemonset/terway-eni`
terway-eniip	v1.0.10.333-gfd2b7b8-aliyun	`kubectl -n kube-system rollout restart daemonset/terway-eniip`
terway-controlplane	v1.2.1	`kubectl -n kube-system rollout restart deployment/terway-controlplane`	なし
flexvolume	v1.14.8.109-649dc5a-aliyun	`kubectl -n kube-system rollout restart daemonset/flexvolume`	FlexVolume を CSI に移行します。
csi-plugin	v1.18.8.45-1c5d2cd1-aliyun	`kubectl -n kube-system rollout restart daemonset/csi-plugin`	なし
csi-provisioner	v1.18.8.45-1c5d2cd1-aliyun	`kubectl -n kube-system rollout restart deployment/csi-provisioner`	なし
storage-operator	v1.18.8.55-e398ce5-aliyun	`kubectl -n kube-system rollout restart deployment/storage-auto-expander kubectl -n kube-system rollout restart deployment/storage-cnfs kubectl -n kube-system rollout restart deployment/storage-monitor kubectl -n kube-system rollout restart deployment/storage-snapshot-manager kubectl -n kube-system rollout restart deployment/storage-operator`	なし
alicloud-disk-controller	v1.14.8.51-842f0a81-aliyun	`kubectl -n kube-system rollout restart deployment/alicloud-disk-controller`	なし
ack-node-problem-detector	1.2.16	`kubectl -n kube-system rollout restart deployment/ack-node-problem-detector-eventer`	なし
aliyun-acr-credential-helper	v23.02.06.2-74e2172-aliyun	`kubectl -n kube-system rollout restart deployment/aliyun-acr-credential-helper`	コンポーネントをアップグレードする前に、まず権限を付与する必要があります。カスタム RAM 権限がなく、アカウント間でイメージをプルする必要がない場合は、[コンポーネント管理] ページに移動してコンポーネント構成を変更します。[tokenMode] が [managedRole] に設定されていることを確認してください。このコンポーネントが提供するプライベートイメージのパスワードなしのイメージプル機能が必要ない場合は、コンポーネントをアンインストールできます。
ack-cost-exporter	1.0.10	`kubectl -n kube-system rollout restart deployment/ack-cost-exporter`	コンポーネントをアップグレードする前に、まず権限を付与する必要があります。
mse-ingress-controller	1.1.5	`kubectl -n mse-ingress-controller rollout restart deployment/ack-mse-ingress-controller`	コンポーネントをアップグレードする前に、まず権限を付与する必要があります。
arms-prometheus	1.1.11	`kubectl -n arms-prom rollout restart deployment/arms-prometheus-ack-arms-prometheus`	なし
ack-onepilot	3.0.11	`kubectl -n ack-onepilot rollout restart deployment/ack-onepilot-ack-onepilot`	コンポーネントをアップグレードする前に、まず権限を付与する必要があります。

ノードプールを介してインストールされた cluster-autoscaler コンポーネント

コンポーネント名

最小コンポーネントバージョン

次のコマンドを実行して再デプロイします

備考

cluster-autoscaler

v1.3.1-bcf13de9-aliyun

kubectl -n kube-system rollout restart deployment/cluster-autoscaler

cluster-autoscaler コンポーネントのバージョンは、次の 2 つの方法で表示できます。コンポーネントのバージョンをアップグレードするには、「[コンポーネントのアップグレード] cluster-autoscaler のアップグレードに関するお知らせ」をご参照ください。

Container Service for Kubernetes (ACK) コンソールでバージョンを表示します。詳細については、「cluster-autoscaler コンポーネントのバージョンを表示する方法」をご参照ください。
次のコマンドを実行して、コンポーネントのバージョンを表示します。
```
kubectl -n kube-system get deployment/cluster-autoscaler -o yaml | grep acs/autoscaler
```

Terway コンポーネント構成の確認

terway、terway-eni、または terway-eniip コンポーネントがクラスターにインストールされている場合は、Terway 構成ファイルも手動で確認する必要があります。これを行うには、kube-system 名前空間の eni-config という名前の ConfigMap の eni_conf 構成の内容を確認します。

次のコマンドを実行して、Terway ConfigMap を編集および表示します。
```
kubectl edit cm eni-config -n kube-system
```
- ファイルに設定項目 "credential_path": "/var/addon/token-config", が含まれている場合は、それ以上のアクションは必要ありません。
- ファイルに設定項目 "credential_path": "/var/addon/token-config", が含まれていない場合は、eni_conf 構成を手動で変更する必要があります。min_pool_size 設定項目の下に "credential_path": "/var/addon/token-config", の行を追加します。
```
"credential_path": "/var/addon/token-config",
```
対応するデプロイメントコマンドを実行して、Terway コンポーネントのワークロードを再デプロイします。

ステップ 3: 監査ログを収集する

テストクラスターによって生成されたログを分析するには、API 操作の監査ログを収集する必要があります。これにより、クラスター内のアプリケーションが Worker RAM ロールに付与されたアクセスポリシーにまだ依存しているかどうかを確認できます。ActionTrail がサポートする Alibaba Cloud サービスの詳細については、「サポートされている Alibaba Cloud サービス」をご参照ください。

説明

少なくとも 1 週間は監査ログを収集してください。

ActionTrail コンソールで、クラスターが配置されているリージョンのシングルアカウントトレイルを作成します。トレイルを作成するときは、[イベントを Simple Log Service (SLS) に配信する] を選択します。詳細については、「シングルアカウントトレイルの作成」をご参照ください。

ステップ 4: クラスター機能をテストする

制限操作を完了したら、クラスターの基本機能をテストして、システムコンポーネントが期待どおりに動作することを確認する必要があります。

基本機能	基本テストケース	リファレンス
コンピューティング	ノードは期待どおりにスケールアウトおよびスケールインできます。	ノードプールの手動スケーリング
ネットワーク	IP アドレスは期待どおりに Pod に割り当てることができます。	デプロイメントとリリース
ストレージ	外部ストレージを使用するワークロードは、期待どおりにデプロイできます (この機能が使用されている場合) 。	ストレージ - CSI
モニタリング	モニタリングおよびアラートデータは、期待どおりに取得できます。	可観測性
伸縮性	ノードの自動スケーリングは、期待どおりに実装できます (この機能が使用されている場合) 。	ノードの自動スケーリングの有効化
セキュリティ	パスワードなしのイメージプル機能は、期待どおりに使用できます (この機能が使用されている場合) 。	管理対象外のパスワードなしコンポーネントのインストールと使用

重要

クラスターの基本機能をテストした後、クラスターにデプロイされたアプリケーションのビジネスロジックもテストする必要があります。これにより、ビジネスが期待どおりに機能することが保証されます。

ステップ 5: 監査ログを分析する

Simple Log Service コンソールにログインします。
[プロジェクト] セクションで、目的のプロジェクトをクリックします。
[ログストレージ] > [Logstores] タブで、宛先の Logstore をクリックします。
ステップ 3 で指定されたログプロジェクトに属する Logstore に保存されているすべての監査ログをクエリします。Logstore の名前は actiontrail_<trail_name> です。
次のクエリ文を使用して、クラスター内のアプリケーションがセキュリティトークンサービス (STS) トークンを使用して呼び出す OpenAPI 操作をカウントします。
次の文の <worker_role_name> をクラスターの Worker RAM ロールの名前に置き換えます。
```
* and event.userIdentity.userName: <worker_role_name> | select "event.serviceName", "event.eventName", count(*) as total GROUP BY "event.eventName", "event.serviceName"
```

ステップ 6: Worker RAM ロールに付与された権限を制限する

ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、対象のクラスターの名前をクリックします。[基本情報] タブで、[ワーカー RAM ロール] の横にあるリンクをクリックして RAM コンソールを開きます。
[ロール] ページの [権限] タブで、宛先のアクセスポリシーをクリックして [ポリシードキュメント] タブに移動します。次に、[ポリシーの編集] をクリックします。
重要
ポリシードキュメントを変更する前に、既存のポリシードキュメントをバックアップしてください。これにより、必要に応じて権限設定をロールバックできます。
ポリシードキュメントを変更するときは、要件とステップ 5 の監査ログの分析結果に基づいて、不要な権限を削除するかどうかを決定します。たとえば、統計に表示されない action 権限を削除できます。権限が不要であることを確認した場合は、付与されているすべてのアクセスポリシーを取り消すことができます。
システムコンポーネントのワークロードを再デプロイします。詳細については、「ステップ 2」の再デプロイコマンドをご参照ください。
Worker RAM ロールにコンポーネントまたはアプリケーションで必要な最小限の権限のみが付与されるまで、ステップ 4、ステップ 5、およびステップ 6 の制限操作を繰り返します。

リファレンス

ACK の全体的な権限付与システムの詳細については、「権限付与のベストプラクティス」をご参照ください。