Istio v1beta1 認証ポリシーの概要

Istio v1beta1 認証ポリシーの導入、動機、設計原則。

2019 年 11 月 14 日 | Google の Yangmin Zhu 著

Istio 1.4 では、これまでの v1alpha1 ロールベースのアクセス制御（RBAC）ポリシーを大幅に更新した v1beta1 認証ポリシーが導入されました。新しいポリシーでは、以下の向上点がもたらされています。

Istio 構成モデルとの整合。
API の簡略化によるユーザーエクスペリエンスの向上。
複雑さを加えることなく、より多くのユースケース（例: イングレス/エグレスゲートウェイサポート）のサポート。

v1beta1 ポリシーは下位互換性がないため、一度の変換が必要です。このプロセスを自動化するツールが提供されています。以前の構成リソース ClusterRbacConfig、ServiceRole、ServiceRoleBinding は Istio 1.6 以降ではサポートされません。

この記事では、新しい v1beta1 認証ポリシーモデル、その設計目標、v1alpha1 RBAC ポリシーからの移行について説明します。v1beta1 認証ポリシーの詳細な詳細な説明については、認証コンセプトページを参照してください。

v1beta1 認証ポリシーに関するフィードバックは、discuss.istio.io でお待ちしております。

背景

これまで、Istio はサービスにアクセス制御を適用するために RBAC ポリシーを提供していました。これは、ClusterRbacConfig、ServiceRole、ServiceRoleBinding という 3 つ構成リソースを使用して行っていました。ユーザーは、この API を使用して、メッシュレベル、ネームスペースレベル、サービスレベルでアクセス制御を適用できました。他の RBAC ポリシーと同様に、Istio RBAC はロールとバインディングという同じコンセプトを使用してアイデンティティに権限を付与します。

Istio RBAC はこれまで確実に機能していましたが、多くの改良が可能であることがわかりました。

たとえば、ユーザーは、ServiceRoleがサービスを使用してポリシーを適用する場所を指定するため、アクセス制御の適用はサービスレベルで行われると誤解しがちです。ただし、ポリシーは実際にはワークロードに適用され、サービスは対応するワークロードを見つけるためにのみ使用されます。このニュアンスは、複数のサービスが同一のワークロードを参照している場合に重要です。サービスAに対するServiceRoleは、2つのサービスが同じワークロードを参照している場合、サービスBにも影響します。これにより混乱や誤った設定が生じる可能性があります。

もう1つの例は、3つの関連リソースを深く理解する必要があるため、ユーザーがIstio RBACの設定を保守および管理することが難しいことが実証されていることです。

デザインの目標

新しいv1beta1認証ポリシーには、いくつかのデザイン目標がありました。

ポリシー対象の明確化のためにIstioの構成モデルと整合。構成モデルは、統合された構成階層、解決、および対象の選択を提供します。
APIの簡素化によるユーザーエクスペリエンスの向上。複数のCRDではなく、すべてのアクセス制御仕様を含むカスタムリソース定義（CRD）を1つ管理する方が簡単です。
複雑さを加えることなく、より多くのユースケースをサポート。たとえば、ポリシーをイン/エグレスゲートウェイに適用して、メッシュに出入りするトラフィックに対するアクセス制御を適用します。

`認証ポリシー`

AuthorizationPolicyカスタムリソースは、ワークロードに対するアクセス制御を可能にします。このセクションでは、v1beta1認証ポリシーの変更の概要を説明します。

AuthorizationPolicyには、selectorとruleのリストが含まれます。selectorはポリシーを適用するワークロードを指定し、ruleのリストはワークロードの詳細なアクセス制御ルールの指定します。

ruleは加算されます。つまり、任意のruleが要求を許可する場合、要求が許可されます。各ruleにはfrom、to、およびwhenのリストが含まれます。これらは、誰がどのような条件で何ができるかを指定します。

selectorはClusterRbacConfigとServiceRoleのservicesフィールドで提供される機能を置き換えます。ruleはServiceRoleとServiceRoleBindingの他のフィールドを置き換えます。

例

次の認証ポリシーは、foo名前空間でapp: httpbinおよびversion: v1ラベルを持つワークロードに適用されます。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: httpbin
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 rules:
 - from:
   - source:
       principals: ["cluster.local/ns/default/sa/sleep"]
   to:
   - operation:
       methods: ["GET"]
   when:
   - key: request.headers[version]
     values: ["v1", "v2"]

このポリシーは、リクエストに値がv1またはv2のversionヘッダーが含まれている場合、プリンシパルcluster.local/ns/default/sa/sleepがGETメソッドを使用してワークロードにアクセスすることを許可します。ポリシーに一致しないリクエストは、すべてデフォルトで拒否されます。

httpbinサービスが次のように定義されていると仮定します。

apiVersion: v1
kind: Service
metadata:
  name: httpbin
  namespace: foo
spec:
  selector:
    app: httpbin
    version: v1
  ports:
    # omitted

v1alpha1 で同じ結果を得るには、3 つのリソースを設定する必要があります。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ClusterRbacConfig
metadata:
  name: default
spec:
  mode: 'ON_WITH_INCLUSION'
  inclusion:
    services: ["httpbin.foo.svc.cluster.local"]
---
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: httpbin
  namespace: foo
spec:
  rules:
  - services: ["httpbin.foo.svc.cluster.local"]
    methods: ["GET"]
    constraints:
    - key: request.headers[version]
      values: ["v1", "v2"]
---
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: httpbin
  namespace: foo
spec:
  subjects:
  - user: "cluster.local/ns/default/sa/sleep"
  roleRef:
    kind: ServiceRole
    name: "httpbin"

ワークロードセレクター

v1beta1 認可ポリシーの大きな変更点は、ポリシーをどこで適用するかを指定するためにワークロードセレクターを使用することです。これは、Gateway、Sidecar、EnvoyFilter 設定で使用されるワークロードセレクターと同じものです。

ワークロードセレクターは、ポリシーがサービスではなくワークロードに適用および強制されることを明確にします。ポリシーが複数の異なるサービスで使用されるワークロードに適用される場合、同じポリシーによってすべての異なるサービスへのトラフィックに影響が及びます。

名前空間内のすべてのワークロードにポリシーを適用するには、selector を空のままにしておくことができます。次のポリシーは、名前空間 bar 内のすべてのワークロードに適用されます。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: policy
 namespace: bar
spec:
 rules:
 # omitted

ルート名前空間

ルート名前空間のポリシーは、すべての名前空間に含まれるメッシュ内のすべてのワークロードに適用されます。ルート名前空間は、MeshConfigで構成でき、デフォルト値はistio-systemです。

たとえば、istio-system 名前空間に Istio をインストールし、default と bookinfo 名前空間にワークロードをデプロイしました。ルート名前空間は、デフォルト値から istio-config に変更されます。次のポリシーは、default、bookinfo、istio-system を含むすべての名前空間内のワークロードに適用されます。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: policy
 namespace: istio-config
spec:
 rules:
 # omitted

イングレス/エグレスゲートウェイサポート

v1beta1 認可ポリシーは、イングレス/エグレスゲートウェイにも適用して、メッシュに出入りするトラフィックへのアクセス制御を強制できます。イングレス/エグレスワークロードを選択するようにselectorを変更するだけです。

次のポリシーは、app: istio-ingressgateway ラベルを持つワークロードに適用されます。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: ingress
 namespace: istio-system
spec:
 selector:
   matchLabels:
     app: istio-ingressgateway
 rules:
 # omitted

認可ポリシーは、ポリシーと同じ名前空間に含まれるワークロードにのみ適用されることに注意してください。ただし、ルート名前空間にポリシーが適用されている場合は除きます。

デフォルトのルート名前空間値（つまり istio-system）を変更しない場合、上記のポリシーは すべての 名前空間の app: istio-ingressgateway ラベルを持つワークロードに適用されます。
ルート名前空間を別の値に変更した場合、上記のポリシーは、istio-system 名前空間ののみ app: istio-ingressgateway ラベルを持つワークロードに適用されます。

比較

次の表は、古い v1alpha1 RBAC ポリシーと新しい v1beta1 認可ポリシーの主な違いを示しています。

機能

機能	`v1alpha1` RBAC ポリシー	`v1beta1` 認可ポリシー
API の安定性	`alpha`: 下位互換性がありません	`beta`: 下位互換性が保証されています
CRD の数	3 つ: `ClusterRbacConfig`、`ServiceRole`、`ServiceRoleBinding`	1 つのみ: `AuthorizationPolicy`
ポリシーのターゲット	サービス	ワークロード
デフォルトでの拒否の動作	`ClusterRbacConfig` を設定することによって明示的に有効にします。	`AuthorizationPolicy` とともに暗黙的に有効にします。
イングレス/エグレスゲートウェイサポート	サポートされていません	サポートされています
ポリシー内の `"*"` の値	すべてのコンテンツ（空と非空）に一致します。	非空コンテンツにのみ一致します。

次の表は、v1alpha1 と v1beta1 API の関係を示しています。

`ClusterRbacConfig`

`ClusterRbacConfig.Mode`	`認証ポリシー`
`OFF`	適用されるポリシーなし
`有効`	ルート名前空間に適用された全拒否ポリシー
`ON_WITH_INCLUSION`	ポリシーは、`ClusterRbacConfig`によって含まれる名前空間またはワークロードに適用される必要があります
`ON_WITH_EXCLUSION`	ポリシーは、`ClusterRbacConfig`によって除外される名前空間またはワークロードに適用される必要があります

`サービスロール`

`サービスロール`	`認証ポリシー`
`サービス`	`セレクター`
`パス`	`to`内の`パス`
`メソッド`	`to`内の`メソッド`
制約内の`destination.ip`	サポートされていません
制約内の`destination.port`	`to`内の`ポート`
制約内の`destination.labels`	`セレクター`
制約内の`destination.namespace`	ポリシーの名前空間、つまりメタデータ内の`namespace`に置き換える
制約内の`destination.user`	サポートされていません
制約内の`experimental.envoy.filters`	`when`内の`experimental.envoy.filters`
制約内の`request.headers`	`when`内の`request.headers`

`サービスロールバインディング`

`サービスロールバインディング`	`認証ポリシー`
`ユーザー`	`from`内の`principals`
`グループ`	`when`内の`request.auth.claims[group]`
プロパティ内の`source.ip`	`from`内の`ipBlocks`
プロパティ内の`source.namespace`	`from`内の`namespaces`
プロパティ内の`source.principal`	`from`内の`principals`
プロパティ内の`request.headers`	`when`内の`request.headers`
プロパティ内の`request.auth.principal`	`from`内の`requestPrincipals`または`when`内の`request.auth.principal`
プロパティ内の`request.auth.audiences`	`when`内の`request.auth.audiences`
プロパティ内の`request.auth.presenter`	`when`内の`request.auth.presenter`
プロパティ内の`request.auth.claims`	`when`内の`request.auth.claims`

多様な違いに関係なく、v1beta1ポリシーはEnvoy内の同じエンジンによって適用され、v1alpha1ポリシーと同じ認証済みID（相互TLSまたはJWT）、条件、その他の基本要素（IP、ポートなど）をサポートします。

`v1alpha1`ポリシーの将来

v1alpha1 RBACポリシー（ClusterRbacConfig、ServiceRole、ServiceRoleBinding）は、v1beta1認証ポリシーによって非推奨になりました。

Istio 1.4は、アルファポリシーから離れるために十分な時間を確保するために、v1alpha1 RBACポリシーを引き続きサポートします。

`v1alpha1`ポリシーからの移行

Istioは特定のワークロードに対して2つのバージョンのいずれかをサポートしています。

ワークロードに対してv1beta1ポリシーのみがある場合は、v1beta1ポリシーが使用されます。
ワークロードに対してv1alpha1ポリシーのみがある場合は、v1alpha1ポリシーが使用されます。
ワークロードに対してv1beta1とv1alpha1の両方のポリシーがある場合は、v1beta1ポリシーのみが使用され、v1alpha1ポリシーは無視されます。

一般的なガイドライン

v1beta1ポリシーに移行する一般的な流れは、RBACが有効になっている名前空間またはサービスを決定するために、ClusterRbacConfigを確認することから始めます。

RBACが有効になっているサービスごとに

サービス定義からワークロードセレクターを取得します。
ワークロードセレクターを使用してv1beta1ポリシーを作成します。
サービスに適用されている各ServiceRoleとServiceRoleBindingに対してv1beta1ポリシーを更新します。
v1beta1 ポリシーを適用してトラフィックを監視し、ポリシーが期待通りに機能していることを確認します。
RBAC が有効になっている次のサービスに対してプロセスを繰り返します。

RBAC が有効になっている各名前空間について

対象の名前空間へのすべてのトラフィックを拒否する v1beta1 ポリシーを適用します。

移行例

foo 名前空間に httpbin サービスについて以下の v1alpha1 ポリシーがあるとします。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ClusterRbacConfig
metadata:
  name: default
spec:
  mode: 'ON_WITH_INCLUSION'
  inclusion:
    namespaces: ["foo"]
---
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: httpbin
  namespace: foo
spec:
  rules:
  - services: ["httpbin.foo.svc.cluster.local"]
    methods: ["GET"]
---
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: httpbin
  namespace: foo
spec:
  subjects:
  - user: "cluster.local/ns/default/sa/sleep"
  roleRef:
    kind: ServiceRole
    name: "httpbin"

次のようにして上記のポリシーを v1beta1 に移行します。

httpbin サービスに次のワークロードセレクターがあるとします。
```
selector:
  app: httpbin
  version: v1
```

ワークロードセレクターで v1beta1 ポリシーを作成します。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: httpbin
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1

ServiceRole とサービスに適用された ServiceRoleBinding のそれぞれで v1beta1 ポリシーを更新します。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: httpbin
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 rules:
 - from:
   - source:
       principals: ["cluster.local/ns/default/sa/sleep"]
   to:
   - operation:
       methods: ["GET"]

v1beta1 ポリシーを適用し、期待通りに機能することを確認するためにトラフィックを監視します。
foo 名前空間は RBAC が有効になっているため、foo 名前空間へのすべてのトラフィックを拒否する以下の v1beta1 ポリシーを適用します。
```
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: deny-all
 namespace: foo
spec:
 {}
```

v1beta1 ポリシーが期待通りに機能することを確認してから、クラスタから v1alpha1 ポリシーを削除できます。

移行の自動化

移行を容易にするために、istioctl experimental authz convert コマンドが提供され、v1alpha1 ポリシーを v1beta1 ポリシーに自動的に変換します。

コマンドを評価できますが、Istio 1.4 では実験的であり、このブログ記事の時点で v1alpha1 セマンティクスを完全にサポートしていません。

v1alpha1 セマンティクスを完全にサポートするコマンドは、Istio 1.4 に続くパッチリリースで期待されています。

Istio v1beta1 認証ポリシーの概要

背景

デザインの目標

認証ポリシー

例

ワークロードセレクター

ルート名前空間

イングレス/エグレスゲートウェイサポート

比較

機能

ClusterRbacConfig

サービスロール

サービスロールバインディング

v1alpha1ポリシーの将来

v1alpha1ポリシーからの移行

一般的なガイドライン

移行例

移行の自動化

`認証ポリシー`

`ClusterRbacConfig`

`サービスロール`

`サービスロールバインディング`

`v1alpha1`ポリシーの将来

`v1alpha1`ポリシーからの移行