Istio 認可によるマイクロセグメンテーション

Istioの認可機能とその様々なユースケースでの使用方法について説明します。

2018年7月20日 | 執筆者：Limin Wang

マイクロセグメンテーションは、クラウドデプロイメントにセキュアゾーンを作成し、組織がワークロードを相互に分離し、個別に保護できるようにするセキュリティ技術です。 Istioの認可機能（Istioロールベースアクセス制御とも呼ばれます）は、Istioメッシュ内のサービスにマイクロセグメンテーションを提供します。その機能は次のとおりです。

このブログ記事では、主な認可機能と、さまざまな状況での使用方法について説明します。

特性

RPCレベルの認可

認可は個々のRPCレベルで実行されます。具体的には、「誰が私のbookstoreサービスにアクセスできるか」、または「誰が私のbookstoreサービスのgetBookメソッドにアクセスできるか」を制御します。「ストレージバケットXへのアクセス」や「2番目の棚にある3番目の書籍へのアクセス」など、アプリケーション固有のリソースインスタンスへのアクセスを制御するためのものではありません。現在、この種類のアプリケーション固有のアクセス制御ロジックは、アプリケーション自体で処理する必要があります。

条件付きロールベースアクセス制御

認可はロールベースアクセス制御（RBAC）システムであり、属性ベースアクセス制御（ABAC）システムとは対照的です。ABACと比較して、RBACには次の利点があります。

一方、Istioの認可システムは従来のRBACシステムではありません。また、ユーザーは属性の組み合わせを使用して**条件**を定義することもできます。これにより、Istioは複雑なアクセス制御ポリシーを表現するための柔軟性を備えています。実際、**Istio認可が採用している「RBAC + 条件」モデルは、RBACシステムのすべての利点を備えており、通常ABACシステムが提供するレベルの柔軟性をサポートしています。**以下に例をいくつか示します。

高性能

セマンティクスが単純であるため、Istio認可はEnvoyでネイティブ認可サポートとして適用されます。実行時、認可の決定はEnvoyフィルター内で完全にローカルに行われ、外部モジュールへの依存関係はありません。これにより、Istio認可は高性能と可用性を実現できます。

プライマリIDの有無にかかわらず動作

他のRBACシステムと同様に、Istio認可はIDを認識します。Istio認可ポリシーには、クライアントのプリンシパルを表すuserと呼ばれるプライマリIDがあります。

プライマリIDに加えて、IDを定義する任意の条件を指定することもできます。たとえば、クライアントIDを「Bookstoreフロントエンドサービスから呼び出しているユーザーAlice」として指定できます。この場合、呼び出し元のサービス（Bookstoreフロントエンド）とエンドユーザー（Alice）の組み合わせIDが使用されます。

セキュリティを向上させるには、認証機能を有効にし、認可ポリシーで認証済みIDを使用する必要があります。ただし、認可を使用するために強力に認証されたIDは必須ではありません。Istio認可はIDの有無にかかわらず機能します。レガシーシステムで作業している場合、メッシュに相互TLSまたはJWT認証が設定されていない可能性があります。この場合、クライアントを識別する唯一の方法は、たとえばIPアドレスを使用することです。Istio認可を使用して、サービスへのアクセスを許可するIPアドレスまたはIP範囲を制御することもできます。

例

認可タスクでは、Istioの認可機能を使用して、Bookinfoアプリケーションを使用して名前空間レベルおよびサービスレベルのアクセスを制御する方法を示しています。このセクションでは、Istio認可を使用してマイクロセグメンテーションを実現する方法の例をさらに示します。

RBAC + 条件による名前空間レベルのセグメンテーション

frontend名前空間とbackend名前空間にサービスがあるとします。frontend名前空間のすべてのサービスが、backend名前空間でexternalとマークされているすべてのサービスにアクセスできるようにします。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: external-api-caller
  namespace: backend
spec:
  rules:
  - services: ["*"]
    methods: ["*”]
    constraints:
    - key: "destination.labels[visibility]”
      values: ["external"]
---
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: external-api-caller
  namespace: backend
spec:
  subjects:
  - properties:
      source.namespace: "frontend”
  roleRef:
    kind: ServiceRole
    name: "external-api-caller"

上記の`ServiceRole`と`ServiceRoleBinding`は、「*誰が*、*どのような条件下で*、*何を*することが許可されているか」（RBAC + 条件）を表現しています。具体的には、

プライマリIDの有無にかかわらず、サービス/メソッドレベルの分離

サービス/メソッドレベルでよりきめ細かいアクセス制御を実証する別の例を次に示します。最初のステップは、`bookstore`サービスの`/books/*`リソースへのREADアクセスを許可する`book-reader`サービ スロールを定義することです。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: book-reader
  namespace: default
spec:
  rules:
  - services: ["bookstore.default.svc.cluster.local"]
    paths: ["/books/*”]
    methods: ["GET”]

認証済みクライアントIDの使用

この`book-reader`ロールを`bookstore-frontend`サービスに付与するとします。メッシュに対して相互TLS認証を有効にしている場合、サービスアカウントを使用して`bookstore-frontend`サービスを識別できます。`book-reader`ロールを`bookstore-frontend`サービスに付与するには、以下に示すように`ServiceRoleBinding`を作成します。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: book-reader
  namespace: default
spec:
  subjects:
  - user: "cluster.local/ns/default/sa/bookstore-frontend”
  roleRef:
    kind: ServiceRole
    name: "book-reader"

「`qualified-reviewer`グループに属するユーザーのみが書籍を読 むことを許可されている」という条件を追加することで、これをさらに制限することができます。`qualified-reviewer`グループは、JWT認証によって認証されるエンドユーザーIDです。この場合、クライアントサービスID（`bookstore-frontend`）とエンドユーザーID（`qualified-reviewer`）の組み合わせが認可ポリシーで使用されます。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: book-reader
  namespace: default
spec:
  subjects:
  - user: "cluster.local/ns/default/sa/bookstore-frontend"
    properties:
      request.auth.claims[group]: "qualified-reviewer"
  roleRef:
    kind: ServiceRole
    name: "book-reader"

クライアントにIDがない

セキュリティのために、認可ポリシーで認証済みIDを使用することを強くお勧めします。ただし、認証をサポートしていないレガシーシステムがある場合、サービスの認証済みIDがない可能性があります。認証済みIDがなくても、Istio認可を使用してサービスを保護できます。以下の例は、認可ポリシーで許可された送信元IP範囲を指定できることを示しています。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: book-reader
  namespace: default
spec:
  subjects:
  - properties:
      source.ip: 10.20.0.0/9
  roleRef:
    kind: ServiceRole
    name: "book-reader"

まとめ

Istioの認可機能は、名前空間レベル、サービスレベル、およびメソッドレベルの粒度で認可を提供します。RBACシステムとして使いやすく理解しやすい「RBAC + 条件」モデルを採用しながら、通常ABACシステムが提供するレベルの柔軟性を提供します。Istio認可は、Envoyでネイティブに適用されるため、高性能を実現します。Istio認証機能と連携することで最高のセキュリティを提供しますが、Istio認可は、認証を持たないレガシーシステムにアクセス制御を提供するためにも使用できます。

この記事を共有する