認可 – Istio By Example (ja)

認証とは、クライアントの身元を確認することです。一方、認可では、そのクライアントのアクセス権限を確認します。すなわち、「このサービスは、クライアントの要求を実行可能かどうか？」を確認します。

Istioメッシュのすべてのリクエストはデフォルトで許可されていますが、ワークロードのきめ細かなポリシーを定義できるAuthorizationPolicy resourceをIstioは提供します。 IstioはAuthorizationPoliciesをEnvoyで読み取り可能な構成に変換し、その構成をIstioサイドカープロキシにマウントします。そこから、認可ポリシーチェックがサイドカープロキシによって実行されます。それがどのように機能するか見てみましょう。

ここでは、ShoeStoreアプリケーションが Kubernetesの default Namespaceにデプロイされています。3つのHTTPワークロードがあり、それぞれ独自のKubernetes Deployment、Service、ServiceAccountで定義されています。

shoes：ストア内のすべての靴のAPIを公開
users：ストアの購入履歴
inventory：新しい靴モデルをshoesにロードします。

inventoryサービスがshoesサービスにデータを POST できるように認可し、usersサービスへのすべてのアクセスをロックします。これを行うには、shoes 用と users 用の2つの AuthorizationPolicies を作成します。

ポリシーをデプロイする前は、inventoryサービスのアプリケーションコンテナー内からshoesとusersの両方にアクセスできます。

$ curl -X GET shoes
🥾 Shoes service

$ curl -x GET users
👥 Users service

まず、shoes 用のAuthorizationPolicyを作成します。：

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "shoes-writer"
  namespace: default
spec:
  selector:
    matchLabels:
      app: shoes
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/inventory-sa"]
    to:
    - operation:
        methods: ["POST"]

このポリシーでは：

shoes の selector は、app：shoes というラベルの付いたDeploymentに適用されることを意味します。
私たちが許可している source ワークロードには、inventory-sa IDがあります。これは、Kubernetes環境では、inventory-sa サービスアカウントを持つPodのみがshoesにアクセスできることを意味します。（注：サービスアカウントベースの認可ポリシーを使用するには、Istio相互TLS認証を有効にする必要があります。相互TLSにより、ワークロードのサービスアカウント証明書をリクエストで渡すことができます。）
ホワイトリストに登録されている唯一のHTTP操作は POST です。つまり、GET などの他のHTTP操作は拒否されます。

shoes-writer のポリシーを適用したら、inventoryから POST することができます。

$ curl -X POST shoes
🥾 Shoes service

ただし、inventory からの GET リクエストは拒否されます。:

$ curl -X GET shoes
RBAC: access denied

また、users など、inventory 以外のワークロードから POST しようとすると、リクエストが拒否されます。:

$ curl -X POST shoes
RBAC: access denied

次に、usersサービスの「deny-all」ポリシーを作成します。：

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "users-deny-all"
  namespace: default
spec:
  selector:
    matchLabels:
      app: users

このサービスには rules がないことに注意してください。users Deploymentの matchLabels のみです。また、deny-allとallow-all AuthorizationPolicyの違いはわずかであることに注意してください。allow-allポリシーでは、rules: {} を指定します。

このリソースを適用すると、どのサービスからもusersにアクセスできなくなります。：

$ curl users
RBAC: access denied

詳しく学ぶ: