Istio 1.4 より前の Alpha セキュリティポリシーを現在の API に移行する

非推奨となった v1alpha1 セキュリティポリシーから、サポートされている v1beta1 バージョンに移行するためのチュートリアルです。

2021年3月3日 | 著者: Yangmin Zhu (Google), Craig Box (Google)

Istio 1.4 より前のバージョンでは、セキュリティポリシーは v1alpha1 API (MeshPolicy, Policy, ClusterRbacConfig, ServiceRole, ServiceRoleBinding) を使用して構成されていました。初期の導入者からの意見を踏まえ、ポリシーシステムに大幅な改善を加え、Istio 1.4 とともに v1beta1 API をリリースしました。これらの刷新された API (PeerAuthentication, RequestAuthentication, AuthorizationPolicy) は、Istio でポリシーのターゲットを定義する方法を標準化し、ユーザーがポリシーの適用場所を理解しやすくし、必要な構成オブジェクトの数を削減するのに役立ちました。

古い API は Istio 1.4 で非推奨となりました。v1beta1 API が導入されてから 2 つのリリース後、Istio 1.6 では v1alpha1 API のサポートが削除されました。

1.6 より前のバージョンの Istio を使用していて、アップグレードしたい場合は、Alpha セキュリティポリシーオブジェクトを Beta API に移行する必要があります。このチュートリアルは、その移行を支援します。

概要

まず、コントロールプレーンを v1beta1 セキュリティポリシーをサポートするバージョンにアップグレードする必要があります。

Istio 1.5 を中間バージョンとしてアップグレードすることを推奨します。これは、v1alpha1 と v1beta1 の両方のセキュリティポリシーをサポートする唯一のバージョンであるためです。Istio 1.5 でセキュリティポリシーの移行を完了し、v1alpha1 セキュリティポリシーを削除してから、後の Istio バージョンへのアップグレードを続行します。特定のワークロードに対しては、v1beta1 バージョンが v1alpha1 バージョンよりも優先されます。

または、Istio 1.4 から 1.6 以降へのスキップレベルアップグレードを直接行いたい場合は、カナリアアップグレードメソッドを使用して、新しい Istio バージョンを別のコントロールプレーンとしてインストールし、ワークロードを新しいコントロールプレーンに徐々に移行しながら、同時にセキュリティポリシーの移行を完了する必要があります。

いずれの場合も、名前空間の粒度で移行することを推奨します。各名前空間について、名前空間内のワークロードに影響を与えるすべての v1alpha1 ポリシーを見つけ、すべてのポリシーを同時に v1beta1 に移行します。これにより、すべてが期待どおりに動作していることを確認し、次の名前空間に進むことができるため、より安全な移行が可能になります。

主な違い

移行を開始する前に、v1beta1 の認証と認可のドキュメントを読み、v1beta1 ポリシーを理解してください。

既存のすべての v1alpha1 セキュリティポリシーを調べ、どのフィールドが使用されているか、どのポリシーを移行する必要があるかを確認し、以下にリストされている主な違いと比較して、ブロッキングの問題がないことを確認する必要があります（例えば、ベータ版ではサポートされなくなったアルファ版の機能を使用しているなど）。

主な違い	`v1alpha1`	`v1beta1`
API の安定性	後方互換性なし	後方互換性あり
mTLS	`MeshPolicy` と `Policy`	`PeerAuthentication`
JWT	`MeshPolicy` と `Policy`	`RequestAuthentication`
認可	`ClusterRbacConfig`、`ServiceRole`、`ServiceRoleBinding`	`AuthorizationPolicy`
ポリシーターゲット	サービス名ベース	ワークロードセレクターベース
ポート番号	サービスポート	ワークロードポート

v1beta1 セキュリティポリシーの RequestAuthentication は v1alpha1 JWT ポリシーと似ていますが、注目すべき意味論的な変更があります。v1alpha1 JWT ポリシーは、2 つの v1beta1 リソースである RequestAuthentication と AuthorizationPolicy に移行する必要があります。これにより、AuthorizationPolicy の使用により JWT の拒否メッセージが変更されます。アルファ版では、HTTP コード 401 が本文 Origin authentication failed とともに返されます。ベータ版では、HTTP コード 403 が本文 RBAC: access denied とともに返されます。

v1alpha1 JWT ポリシーの triggerRule フィールドは、regex フィールドがサポートされなくなったことを除いて、AuthorizationPolicy に置き換えられます。

移行フロー

このセクションでは、v1alpha1 セキュリティポリシーを移行する方法について詳しく説明します。

各名前空間について、名前空間内のワークロードに影響を与えるすべての v1alpha1 セキュリティポリシーを見つけます。結果には以下が含まれる可能性があります。

メッシュ内のすべてのサービスに適用される単一の MeshPolicy。
名前空間内のすべてのワークロードに適用される単一の名前空間レベルの Policy。
名前空間内の選択されたサービスに適用される複数のサービスレベルの Policy オブジェクト。
名前空間全体または名前空間内のいくつかのサービスで RBAC を有効にする単一の ClusterRbacConfig。
名前空間内のすべてのサービスに適用される複数の名前空間レベルの ServiceRole および ServiceRoleBinding オブジェクト。
名前空間内の選択されたサービスに適用される複数のサービスレベルの ServiceRole および ServiceRoleBinding オブジェクト。

ステップ 2: サービス名をワークロードセレクターに変換する

v1alpha1 ポリシーは、サービス名を使用してターゲットを選択します。v1beta1 ポリシーで使用する必要があるワークロードセレクターを決定するには、対応するサービス定義を参照する必要があります。

単一の v1alpha1 ポリシーに複数のサービスが含まれる場合があります。v1beta1 ポリシーは現在、ポリシーごとに最大 1 つのワークロードセレクターしかサポートしていないため、複数の v1beta1 ポリシーに移行する必要があります。

また、v1alpha1 ポリシーはサービスポートを使用しますが、v1beta1 ポリシーはワークロードポートを使用することに注意してください。これは、移行された v1beta1 ポリシーではポート番号が異なる可能性があることを意味します。

ステップ 3: 認証ポリシーを移行する

各 v1alpha1 認証ポリシーについて、次のルールに従って移行します。

名前空間全体で mTLS または JWT が有効になっている場合は、名前空間全体に対してワークロードセレクターなしで PeerAuthentication、RequestAuthentication、および AuthorizationPolicy を作成します。名前空間に対応する MeshPolicy または Policy のセマンティクスに基づいてポリシーを設定します。
ワークロードで mTLS または JWT が有効になっている場合は、ワークロードに対応するワークロードセレクターを使用して PeerAuthentication、RequestAuthentication、および AuthorizationPolicy を作成します。ワークロードに対応する MeshPolicy または Policy のセマンティクスに基づいてポリシーを設定します。
mTLS 関連の構成については、アルファポリシーが STRICT を使用している場合は STRICT モードを使用し、それ以外の場合はすべて PERMISSIVE を使用します。
JWT 関連の構成については、エンドユーザー認証 ドキュメントを参照して、RequestAuthentication および AuthorizationPolicy への移行方法を学んでください。

セキュリティポリシー移行ツールが提供されており、認証ポリシーを自動的に移行できます。使用方法については、ツールの README を参照してください。

ステップ 4: RBAC ポリシーを移行する

各 v1alpha1 RBAC ポリシーについて、次のルールに従って移行します。

名前空間全体で RBAC が有効になっている場合は、名前空間全体に対してワークロードセレクターなしで AuthorizationPolicy を作成します。名前空間へのすべてのリクエストをデフォルトで拒否するように、空のルールを追加します。
ワークロードで RBAC が有効になっている場合は、ワークロードに対応するワークロードセレクターを使用して AuthorizationPolicy を作成します。ワークロードに対応する ServiceRole および ServiceRoleBinding のセマンティクスに基づいてルールを追加します。

ステップ 5: 移行されたポリシーを確認する

移行された v1beta1 ポリシーを再確認します。名前が重複しているポリシーがないこと、名前空間が正しく指定されていること、および指定された名前空間のすべての v1alpha1 ポリシーが移行されていることを確認します。
コマンド kubectl apply --dry-run=server -f beta-policy.yaml を使用して v1beta1 ポリシーをドライランし、有効であることを確認します。
v1beta1 ポリシーを指定された名前空間に適用し、効果を注意深く監視します。JWT または承認を使用する場合は、許可シナリオと拒否シナリオの両方を必ずテストしてください。
次の名前空間を移行します。すべての名前空間の移行が正常に完了した後でのみ、v1alpha1 ポリシーを削除します。

例

`v1alpha1` ポリシー

このセクションでは、名前空間 foo の移行を示す完全な例を示します。名前空間 foo には、その中のワークロードに影響を与える次の v1alpha1 ポリシーがあるとします。

# A MeshPolicy that enables mTLS globally, including the whole foo namespace
apiVersion: "authentication.istio.io/v1alpha1"
kind: "MeshPolicy"
metadata:
  name: "default"
spec:
  peers:
  - mtls: {}
---
# A Policy that enables mTLS permissive mode and enables JWT for the httpbin service on port 8000
apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: httpbin
  namespace: foo
spec:
  targets:
  - name: httpbin
    ports:
    - number: 8000
  peers:
  - mtls:
      mode: PERMISSIVE
  origins:
  - jwt:
      issuer: testing@example.com
      jwksUri: https://www.example.com/jwks.json
      triggerRules:
      - includedPaths:
        - prefix: /admin/
        excludedPaths:
        - exact: /admin/status
  principalBinding: USE_ORIGIN
---
# A ClusterRbacConfig that enables RBAC globally, including the foo namespace
apiVersion: "rbac.istio.io/v1alpha1"
kind: ClusterRbacConfig
metadata:
  name: default
spec:
  mode: 'ON'
---
# A ServiceRole that enables RBAC for the httpbin service
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: httpbin
  namespace: foo
spec:
  rules:
  - services: ["httpbin.foo.svc.cluster.local"]
    methods: ["GET"]
---
# A ServiceRoleBinding for the above ServiceRole
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: httpbin
  namespace: foo
spec:
  subjects:
  - user: cluster.local/ns/foo/sa/sleep
    roleRef:
      kind: ServiceRole
      name: httpbin

`httpbin` サービス

httpbin サービスには、次の定義があります。

apiVersion: v1
kind: Service
metadata:
  name: httpbin
  namespace: foo
spec:
  ports:
  - name: http
    port: 8000
    targetPort: 80
  selector:
    app: httpbin

これは、サービス名 httpbin をワークロードセレクター app: httpbin に置き換え、サービスポート 8000 をワークロードポート 80 に置き換える必要があることを意味します。

`v1beta1` 認証ポリシー

foo 名前空間の v1alpha1 認証ポリシーに対して移行された v1beta1 ポリシーを以下に示します。

# A PeerAuthentication that enables mTLS for the foo namespace, migrated from the MeshPolicy
# Alternatively the MeshPolicy could also be migrated to a PeerAuthentication at mesh level
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: foo
spec:
  mtls:
    mode: STRICT
---
# A PeerAuthentication that enables mTLS for the httpbin workload, migrated from the Policy
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: httpbin
  namespace: foo
spec:
  selector:
    matchLabels:
      app: httpbin
  # port level mtls set for the workload port 80 corresponding to the service port 8000
  portLevelMtls:
    80:
      mode: PERMISSIVE
--
# A RequestAuthentication that enables JWT for the httpbin workload, migrated from the Policy
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: httpbin
  namespace: foo
spec:
  selector:
    matchLabels:
      app: httpbin
  jwtRules:
  - issuer: testing@example.com
    jwksUri: https://www.example.com/jwks.json
---
# An AuthorizationPolicy that enforces to require JWT validation for the httpbin workload, migrated from the Policy
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin-jwt
  namespace: foo
spec:
  # Use DENY action to explicitly deny requests without JWT token
  action: DENY
  selector:
    matchLabels:
      app: httpbin
  rules:
  - from:
    - source:
        # This makes sure requests without JWT token will be denied
        notRequestPrincipals: ["*"]
    to:
    - operation:
        # This should be the workload port 80, not the service port 8000
        ports: ["80"]
        # The path and notPath is converted from the trigger rule in the Policy
        paths: ["/admin/*"]
        notPaths: ["/admin/status"]

`v1beta1` 認可ポリシー

foo 名前空間の v1alpha1 RBAC ポリシーに対して移行された v1beta1 ポリシーを以下に示します。

# An AuthorizationPolicy that denies by default, migrated from the ClusterRbacConfig
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: default
  namespace: foo
spec:
  # An empty rule that allows nothing
  {}
---
# An AuthorizationPolicy that enforces to authorization for the httpbin workload, migrated from the ServiceRole and ServiceRoleBinding
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin
  namespace: foo
spec:
  selector:
    matchLabels:
      app: httpbin
      version: v1
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/foo/sa/sleep"]
    to:
    - operation:
        methods: ["GET"]

アップグレードを完了する

おめでとうございます。この時点に到達すると、v1beta1 ポリシーオブジェクトのみが存在し、Istio を 1.6 以降にアップグレードし続けることができます。

Istio 1.4 より前の Alpha セキュリティポリシーを現在の API に移行する

概要

主な違い

移行フロー

ステップ 1: 関連するポリシーを見つける

ステップ 2: サービス名をワークロードセレクターに変換する

ステップ 3: 認証ポリシーを移行する

ステップ 4: RBAC ポリシーを移行する

ステップ 5: 移行されたポリシーを確認する

例

v1alpha1 ポリシー

httpbin サービス

v1beta1 認証ポリシー

v1beta1 認可ポリシー

アップグレードを完了する

`v1alpha1` ポリシー

`httpbin` サービス

`v1beta1` 認証ポリシー

`v1beta1` 認可ポリシー