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

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

始める前に

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

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

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

  2. 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.

    Go to project selector

  3. Verify that billing is enabled for your Google Cloud project.

  4. Enable the Network Security, Network Services APIs, if any are not already enabled.

    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

  5. 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.

    Go to project selector

  6. Verify that billing is enabled for your Google Cloud project.

  7. Enable the Network Security, Network Services APIs, if any are not already enabled.

    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

    8.

名前空間全体の AuthzPolicy

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

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

空の selector: {} は、Namespace 内のすべての Pod をターゲットにします。

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

cat >ns-authz-policy-allow.yaml <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: ns-authz
  namespace: NAMESPACE
spec:
  targetRefs:
  - group: ""
    kind: Pod
    selector: {}
  rules:
  - to:
      operations:
      - paths:
        - type: Prefix
          value: "/headers"
        methods: ["GET"]
  action: ALLOW
  enforcementLevel: L7
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:
  - group: ""
    kind: Pod
    selector:
      matchLabels:
        app: EXAMPLE_APP
  rules:
  - to:
      operations:
      - paths:
        - type: Prefix
          value: "/deny_path"
  action: DENY
  enforcementLevel: L7
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:
  - group: ""
    kind: Pod
    selector:
      matchLabels:
        app: EXAMPLE_APP
  rules:
  - from:
      sources:
      - principals:
        - principal:
            type: Exact
            value: "spiffe://cluster.local/NAMESPACE/pod1"
  action: ALLOW
  enforcementLevel: L7
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: NAMESPACE
spec:
  backendRef:
    group: ""
    kind: Service
    name: authz-service
    port: PORT
  authority: "authz-service.NAMESPACE.svc.cluster.local"
  forwardHeaders:
  - Authorization
  failOpen: false
  timeout: "100ms"
  wireFormat: ExtProcGRPC
EOF
kubectl apply -f authz-extension.yaml

    次のように置き換えます。

    • NAMESPACE: authz-service Service とワークロードの Namespace。
    • PORT: ext_proc gRPC API を提供する authz-service Service のポート。

    このコマンドは、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:
  - group: ""
    kind: Pod
    selector:
      matchLabels:
        app: EXAMPLE_APP
  rules:
  - from:
      sources:
      - principals:
        - principal:
            type: Exact
            value: "spiffe://cluster.local/NAMESPACE/pod1"
    to:
      operations:
      - paths:
        - type: Exact
          value: "/api/payments-schedule"
  action: CUSTOM
  enforcementLevel: L7
  customProviders:
    extensionRefs:
    - group: networking.gke.io
      kind: GCPAuthzExtension
      name: my-authz-ext
EOF
kubectl apply -f authz-policy.yaml

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

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

    プロキシは、認可拡張機能が応答するまで待機してから、リクエストをアプリケーションに転送します。拡張機能がエラーで呼び出しを終了してリクエストを拒否した場合、または failOpen が false のときに呼び出しが失敗またはタイムアウトした場合、呼び出し元は HTTP 500 レスポンスを受け取ります。拡張機能が即時レスポンスを送信すると、呼び出し元はそのレスポンスからステータス コードを受け取ります。