# Dynamic Engine環境で実行されるタスクコンテナのsecurityContextの設定

デフォルトのコンテナsecurityContextを上書きして、特定のユーザーIDとグループIDでタスクを実行します。これにより、きめ細かな権限制御が可能になり、セキュリティ体制が強化され、異なるユーザーIDやグループIDのためにコンテナイメージを再構築することなく、コンプライアンス要件を満たすことができます。

## 始める前に

[前提条件および重要な考慮事項](https://help.qlik.com/talend/ja-JP/dynamic-engine-configuration-guide/Cloud/custom-kubernetes-resource-mounting)をご覧ください。

## このタスクについて

このパターンは、セキュリティが重視される環境、コンプライアンス要件のあるデプロイメント、マウントされたボリュームに特定のUID/GIDの一致が必要なシナリオにおいて不可欠です。

## 手順

1. コンテナに適したユーザーID (UID)とグループID (GID)を決定します。

   ニーズに基づいてUID/GIDの組み合わせを選択します。securityContextの要件とベストプラクティスの詳細については、「[Kubernetes Security Contextのドキュメント](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)」を参照してください。
2. securityContextを設定するHelm値ファイルを作成します。
   ### 例

   security-context-values.yamlという名前のファイルを作成します。
   ```
   configuration:
     # For Data Integration and Big Data Job tasks
     jobDeployment:
       additionalSpec:
         enabled: true
         securityContext:
           runAsUser: <user_ID>
           runAsGroup: <group_ID>
           fsGroup: <group_ID>
           runAsNonRoot: true

     # For Data Service and Route tasks
     dataServiceRouteDeployment:
       additionalSpec:
         enabled: true
         securityContext:
           runAsUser: <user_ID>
           runAsGroup: <group_ID>
           fsGroup: <group_ID>
           runAsNonRoot: true
   ```

   securityContext内の各フィールドの意味については、「[Kubernetes Security Contextのドキュメント](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)」を参照してください。
3. securityContext設定を使用して、Dynamic Engine環境をデプロイまたはアップグレードします。
   ```
   helm upgrade --install dynamic-engine-environment-$DYNAMIC_ENGINE_ENVIRONMENT_ID \
     oci://ghcr.io/talend/helm/dynamic-engine-environment \
     --version ${DYNAMIC_ENGINE_VERSION} \
     -f $DYNAMIC_ENGINE_ENVIRONMENT_ID-values.yaml \
     -f security-context-values.yaml
   ```

   $DYNAMIC\_ENGINE\_ENVIRONMENT\_IDを自分の環境IDに、${DYNAMIC\_ENGINE\_VERSION}を環境のバージョンにそれぞれ置き換えます。

   このコマンドを実行すると、Dynamic Engine環境とそれに関連付けられたネームスペースqlik-processing-env-$DYNAMIC\_ENGINE\_ENVIRONMENT\_IDが作成され、タスクコンテナにsecurityContextの設定が適用されます。securityContextはポッドの仕様設定の一部であり(個別のKubernetesリソースではないため)、この単一の手順で直接適用できます。
4. 実行中のポッドのsecurityContextを確認します。
   ```
   kubectl get pod <pod_name> -n qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID \
     -o jsonpath='Pod Security Context: {.spec.securityContext}{"\n"}Container Security Context: {.spec.containers[0].securityContext}{"\n"}'
   ```

   想定される出力には、設定済みのsecurityContextが表示されます。
   ```
   Pod Security Context: {"fsGroup":<group_id>,"runAsGroup":<group_id>,"runAsNonRoot":true,"runAsUser":<user_id>}
   Container Security Context: {"allowPrivilegeEscalation":false,"capabilities":{"drop":["ALL"]},"runAsNonRoot":true,"seccompProfile":{"type":"RuntimeDefault"}}
   ```

## タスクの結果

Dynamic Engineデータ統合タスク(ビッグ データを含む)、データサービス、ルートタスクは、securityContextで指定された制限付きの非ルートユーザーIDを使用して実行されるようになりました。これにより、セキュリティ体制が強化され、セキュリティ標準への準拠が確保され、権限のないコンテナが機密リソースにアクセスすることを防止できます。