GKE のサイドカーで認可ポリシーを設定する

プレビュー - サイドカーの認可ポリシー

この機能は、サービス固有規約の「一般サービス規約」セクションの「一般提供前のサービス規約」の対象となります。pre-GA の機能は「現状のまま」で提供されるものであり、サポートが制限されることがあります。 詳細については、リリース ステージの説明をご覧ください。

このページでは、GKE の Cloud Service Mesh サイドカーにさまざまな種類の認可ポリシーを設定する手順について説明します。

始める前に

Gateway API と認可拡張機能について理解しておく必要があります。

認可ポリシーを作成する前に、次の手順を行う必要があります。

Google Cloud アカウントにログインします。 Google Cloudを初めて使用する場合は、 アカウントを作成して、実際のシナリオでの Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Network Security, Network Services APIs.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

Enable the APIs

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Network Security, Network Services APIs.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

Enable the APIs

Namespace-wide AuthzPolicy

名前空間全体の想定されるトラフィック パターンを拒否する場合は、名前空間内のすべてのワークロードへの受信 HTTP リクエストを拒否するように認可ポリシーを構成します。

cat >ns-authz-policy-deny.yaml <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: ns-authz
  namespace: NAMESPACE
spec:
  targetRefs:
  - kind: Pod
    selector: {}
  rules:
  - to:
      operations:
      - paths:
        - type: Prefix
          value: "/bad_token"
  action: DENY
EOF
kubectl apply -f ns-authz-policy-deny.yaml

空の selector: {} は Namespace 内のすべての Pod をターゲットにしていることに注意してください。

名前空間全体の想定されるトラフィック パターンを許可する場合は、名前空間内のすべてのワークロードへの受信 HTTP リクエストを許可するように認可ポリシーを構成します。

cat >ns-authz-policy-allow.yaml <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: ns-authz
  namespace: NAMESPACE
spec:
  targetRefs:
  - kind: Pod
    selector: {}
  rules:
  - to:
      operations:
      - paths:
        - type: Prefix
          value: "/headers"
        methods: ["GET"]
  action: ALLOW
EOF
kubectl apply -f ns-authz-policy-allow.yaml

空の selector: {} は Namespace 内のすべての Pod をターゲットにしていることに注意してください。

ワークロードへのインバウンド リクエストを拒否する

cron ジョブなど、発信のみを行うワークロードがある場合は、ワークロードへの受信 HTTP リクエストを拒否するように認可ポリシーを構成します。

cat >deny-path-authz-policy.yaml <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: my-workload-authz
  namespace: NAMESPACE
spec:
 targetRefs:
 - kind: Pod
   selector:
matchLabels:
      app: EXAMPLE_APP
  rules:
  - to:
      operations:
      - paths:
        - type: Prefix
          value: "/deny_path"
  action: DENY
EOF
kubectl apply -f deny-path-authz-policy.yaml

出力は次のようになります。

gcpauthzpolicy.networking.gke.io/my-workload-authz created

このポリシーが適用されると、app: EXAMPLE_APP に一致する Pod のパス /deny_path への受信 HTTP リクエストは拒否され、呼び出し元は HTTP 403 Forbidden レスポンス コードを受け取ります。

ワークロードへの特定のインバウンド リクエストを許可する

特定の条件に一致するリクエストのみを許可し、残りを拒否する ALLOW ポリシーを構成することもできます。

次の例では、ID が spiffe://cluster.local/namespace/pod1 の Pod からの mTLS リクエストのみを許可するように、example-app Deployment で認可ポリシーを構成します。

cat >allow-authz-policy.yaml <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: my-workload-authz
  namespace: NAMESPACE
spec:
 targetRefs:
 - kind: Pod
   selector:
matchLabels:
      app: EXAMPLE_APP
  rules:
  - from:
      sources:
      - principals:
        - principal:
          exact: "spiffe://cluster.local/NAMESPACE/pod1"
  action: ALLOW
EOF
kubectl apply -f allow-authz-policy.yaml

出力は次のようになります。

gcpauthzpolicy.networking.gke.io/my-workload-authz created

正確な SPIFFE ID spiffe://cluster.local/NAMESPACE/pod1 を提示する mTLS を使用して認証された受信リクエストのみが、HTTP 200 OK を受け取ります。他のリクエストは、HTTP 403 Forbidden でプロキシによって拒否されます。

外部認可エンジンに委任する

独自の認可エンジンを導入し、ワークロードのすべての認可判定を構成済みのエンジンに委任するように Cloud Service Mesh を構成できます。

1. GCPAuthzExtension CRD がまだインストールされていない場合は、インストールします。

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-gateway-api/main/config/crd/networking.gke.io_gcpauthzextensions.yaml
   

2. ext_proc gRPC プロトコルをサポートする Kubernetes にコールアウト ベースの認可拡張機能ワークロードをデプロイし、認可拡張機能リソースを構成します。

   cat >authz-extension.yaml <<EOF
   apiVersion: networking.gke.io/v1
   kind: GCPAuthzExtension
   metadata:
     name: my-authz-ext
     namespace: ns1
   spec:
     backendRef:
       kind: Service
       name: authz-service
     loadBalancingScheme: INTERNAL_SELF_MANAGED
     forwardHeaders:
     - Authorization
     failOpen: false
     timeout: "0.1s"
     wireFormat: EXT_PROC_GRPC
   EOF
   kubectl apply -f authz-extension.yaml
   

   このコマンドは、Kubernetes サービス authz-service として実行されるコールアウト ベースの認可拡張機能を作成します。

   出力は次のようになります。

   gcpauthzextension.networking.gke.io/my-authz-ext created
   

3. ワークロードの認可の決定を、以前に構成した認可拡張機能に委任するように認可ポリシーを設定します。

   cat >authz-policy.yaml <<EOF
   apiVersion: networking.gke.io/v1
   kind: GCPAuthzPolicy
   metadata:
     name: my-workload-authz
     namespace: NAMESPACE
   spec:
     targetRefs:
     - kind: Pod
       selector:
         matchLabels:
           app: EXAMPLE_APP
     rules:
     - from:
         sources:
         - principals:
           - principal:
               exact: "spiffe://cluster.local/NAMESPACE/pod1"
       to:
         operations:
         - paths:
           - type: Exact
             value: "/api/payments-schedule"
     action: CUSTOM
     customProvider:
       authzExtension:
         targetRefs:
         - kind: GCPAuthzExtension
           name: my-authz-ext
   EOF
   kubectl apply -f authz-policy.yaml
   

   出力は次のようになります。

   gcpauthzpolicy.networking.gke.io/my-workload-authz created
   

   プロキシは、カスタム サービスが OK または DENY レスポンスを返すまで待機してから、リクエストをアプリケーションに転送するか、呼び出し元に HTTP 403 を返します。