Knative Eventing 認証

追跡イシュー: #7256

概要

Knative Eventingにおけるイベント配信の保護は、不正アクセスを防ぐために不可欠です。イベント配信に対するきめ細かい制御を適用するため、Knative EventingはEventPolicyカスタムリソースを導入しました。これにより、ユーザーは名前空間内の特定のコンシューマーにイベントを送信することを許可されているエンティティを指定できます。

前提条件

• Eventingのインストール
• authentication-oidc機能を有効にする。

注意

authentication-oidcで説明されているように、安全な認証のためにはtransport-encryptionも有効にする必要があります。トランスポート暗号化機能フラグを有効にする方法については、トランスポート暗号化をご覧ください。

互換性

認証は現在、以下のコンポーネントでサポートされています。

• ブローカー
  • MTChannelBasedBroker
  • Apache Kafka用Knative Broker
• チャネル
  • InMemoryChannel
  • KafkaChannel
• フロー
  • Sequence
  • 並列
• その他
  • KafkaSink

デフォルト認証モード

管理者は、defaultAuthorizationMode機能フラグを使用してデフォルトの認証モードを設定できます。これは、リソースにEventPolicyが適用されない場合にKnative Eventingが使用します。利用可能なモードは次のとおりです。

• allow-all：すべてのリクエストが許可されます。
• deny-all：すべてのリクエストが拒否され、EventPolicyの作成が強制されます。
• allow-same-namespace：同じ名前空間内のサブジェクトからのリクエストのみが許可されます。（デフォルト）

EventPolicyの定義

EventPolicyは、指定されたイベントコンシューマーにイベントを送信することを許可されているサブジェクト（サービスアカウントまたはイベントソース）を指定することにより、イベント配信のルールを定義します。

apiVersion: eventing.knative.dev/v1alpha1
kind: EventPolicy
metadata:
  name: my-event-policy
  namespace: default
spec:
  to:
    - ref:
        apiVersion: eventing.knative.dev/v1
        kind: Broker
        name: my-broker
    - selector:
        apiVersion: eventing.knative.dev/v1
        kind: Broker
        matchLabels:
          app: special-app
  from:
    - ref:
        apiVersion: sources.knative.dev/v1
        kind: PingSource
        name: my-source
        namespace: another-namespace
    - sub: system:serviceaccount:default:trusted-app
    - sub: "system:serviceaccount:default:other-*"
  filters:
    - cesql: "type IN ('order.created', 'order.updated', 'order.canceled')"
    - exact:
        type: com.github.push

EventPolicyが適用される対象の指定

.spec.toセクションは、イベントの送信が許可される場所を指定します。このフィールドはオプションです。空のままにすると、ポリシーは名前空間内のすべてのリソースに適用されます。.spec.toに複数のターゲットを指定することにより、EventPoliciesのスコープは、同じルールを複数のターゲットに適用することで広がります。

これらのターゲットを定義する方法は2つあります。

1. to.ref:
   • 定義：特定のリソースを直接参照します。
   • 例：上記のEventPolicyでは、my-broker Brokerが直接参照されています。これは、EventPolicyがこの特定のBrokerに適用されることを意味します。
   • 使用例：名前で特定のリソースを保護する場合は、to.refを使用します。

     to:
       - ref:
           apiVersion: eventing.knative.dev/v1
           kind: Broker
           name: my-broker
     

2. to.selector:

   • 定義：ラベルセレクターを使用して、特定のタイプの複数のリソースを照合します。
   • 例：EventPolicyには、app: special-appに一致するラベルを持つBrokerが含まれています。これは、EventPolicyがこれらのラベルを持つすべてのBrokersに適用されることを意味します。
   • 使用例：共通のラベルを共有するリソースのグループにEventPolicyを適用する場合は、to.selectorを使用します。

   to:
     - selector:
         apiVersion: eventing.knative.dev/v1
         kind: Broker
         matchLabels:
           app: special-app
   

イベント送信を許可する対象の指定

.spec.fromセクションは、.spec.toで定義されたターゲットにイベントを送信することを許可されている対象を指定します。これらのソースを定義する方法は2つあります。

1. from.ref:

   • 定義：特定のイベントソースリソースを直接参照します。
   • 例：another-namespaceのmy-source PingSourceが参照されています。つまり、この特定のソースはイベントを送信することを許可されています。
   • 使用例：特定のイベントソースを認証する場合は、from.refを使用します。

     from:
       - ref:
           apiVersion: sources.knative.dev/v1
           kind: PingSource
           name: my-source
           namespace: another-namespace
     

2. from.sub:

   • 定義：イベント送信を許可されているサブジェクト（サービスアカウント名）を指定します。より広範囲なマッチングのために、ワイルドカードパターンを接尾辞（*）として含めることができます。
   • 例：EventPolicyは、デフォルトの名前空間のtrusted-appサービスアカウントからのイベントと、other-で始まるデフォルト名前空間内のすべてのサービスアカウントからのイベントを許可します。
   • 使用例：特定のユーザーまたはサービスアカウントを許可する場合、またはより柔軟性を持たせるためにワイルドカードパターンを適用する場合は、from.subを使用します。

     from:
       - sub: system:serviceaccount:default:trusted-app
       - sub: "system:serviceaccount:default:other-*"
     

高度なCloudEventフィルタリング条件

.spec.filtersセクションはオプションであり、許可されるためにはイベント自体が満たす必要のある追加の条件を指定します。

• 例：typeがcom.github.pushに等しく、特定のCESQL式に一致するCloudEventsのみが許可されます。
• 使用例：許可されたCloudEventsに関するよりきめ細かい条件を設定する場合は、filtersを使用します。

  from:
    filters:
      - cesql: "type IN ('order.created', 'order.updated', 'order.canceled')"
      - exact:
          type: com.github.push
  

フィルターが指定されている場合、イベントは受け入れられるために、EventPolicyの指定されたすべてのフィルター（.spec.fromに加えて）に一致する必要があります。.spec.filtersは、トリガーと同じフィルターダイアレクトを受け入れます。

注意

フィルターは.spec.fromに加えて適用されます。つまり、EventPolicyが.spec.filtersを指定するとすぐに、それらはリクエストと.spec.from（AND演算子）の両方に一致する必要があります。その場合にのみ、EventPolicyはリクエストを許可します。

.specフィールドの概要：

• to.refは特定のリソースをターゲットにします。
• to.selectorは、ラベルに基づいてリソースのセットをターゲットにします。
• from.refは特定のイベントソースリソースを認証します。
• from.subは、特定のユーザー、サービスアカウント、またはアカウントのパターンを認証します。
• .spec.filtersを使用すると、高度なCloudEventフィルタリング条件を定義できます。

EventPolicyステータス

EventPolicyのステータスは、解決されたソースと準備状況に関する情報を提供します。

status:
  from:
    - system:serviceaccount:default:my-source-oidc-sources.knative.dev-pingsource
    - system:serviceaccount:default:trusted-app
    - "system:serviceaccount:default:other-*"
  conditions:
    - type: Ready
      status: "True"
    - type: SubjectsResolved
      status: "True"

リソースへのEventPolicyの適用

Brokerなどのイベントコンシューマーは、ステータスに適用されているEventPolicyを一覧表示します。

apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  name: my-broker
spec:
  ...
status:
  ...
  policies:
    - name: my-event-policy
      apiVersion: v1alpha1
  conditions:
    - type: Ready
      status: "True"
    - type: EventPoliciesReady
      status: "True"

EventPoliciesReady状態は、リソースに適用可能なすべてのEventPolicyの準備が整い、正常に適用されたかどうかを示します。

拒否動作

リクエストが適用可能なEventPolicyをパスしない場合、不正なイベント配信がブロックされるように、403 Forbidden HTTPステータスコードで拒否されます。複数のポリシーが同じリソースに適用される場合、イベントは、適用可能なEventPoliciesの少なくとも1つに一致する限り配信されます。これにより、厳格なポリシーが適用されている場合でも、ポリシーの基準を満たす有効なイベントは引き続き処理できます。

例

以下に、リソースの認証を構成する方法の完全な例を示します。この例では、別の名前空間（namespace-2）にあるPingSource（pingsource-2）からのリクエストのみを許可することにより、namespace-1のBroker（broker）を保護します。

最初に、名前空間、Broker、PingSourceを作成します。

apiVersion: v1
kind: Namespace
metadata:
  name: namespace-1
---
apiVersion: v1
kind: Namespace
metadata:
  name: namespace-2
---
apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  name: broker
  namespace: namespace-1
---
apiVersion: sources.knative.dev/v1
kind: PingSource
metadata:
  name: pingsource-1
  namespace: namespace-1
spec:
  data: '{"message": "Hi from pingsource-1 from namespace-1"}'
  schedule: '*/1 * * * *'
  sink:
    ref:
      apiVersion: eventing.knative.dev/v1
      kind: Broker
      name: broker
      namespace: namespace-1
---
apiVersion: sources.knative.dev/v1
kind: PingSource
metadata:
  name: pingsource-2
  namespace: namespace-2
spec:
  data: '{"message": "Hi from pingsource-2 from namespace-2"}'
  schedule: '*/1 * * * *'
  sink:
    ref:
      apiVersion: eventing.knative.dev/v1
      kind: Broker
      name: broker
      namespace: namespace-1

デバッグのために、event-display KserviceとTriggerも作成します。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: event-display
  namespace: namespace-1
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/min-scale: "1"
    spec:
      containers:
      - image: gcr.io/knative-releases/knative.dev/eventing/cmd/event_display
---
apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: trigger
  namespace: namespace-1
spec:
  broker: broker
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: event-display

OIDCが無効になっていて、EventPolicyが設定されていない限り、両方のPingSourceからのイベントがevent-display kserviceに表示されます。

$ kubectl -n namespace-1 logs event-display-00001-deployment-56cd8dd644-64xl2
☁️  cloudevents.Event
Context Attributes,
  specversion: 1.0
  type: dev.knative.sources.ping
  source: /apis/v1/namespaces/namespace-1/pingsources/pingsource-1
  id: 79d7a363-798d-40e2-b95c-6e007c81b05b
  time: 2024-08-28T11:33:00.168602384Z
Extensions,
  knativearrivaltime: 2024-08-28T11:33:00.194124454Z
Data,
  {"message": "Hi from pingsource-1 from namespace-1"}
☁️  cloudevents.Event
Context Attributes,
  specversion: 1.0
  type: dev.knative.sources.ping
  source: /apis/v1/namespaces/namespace-2/pingsources/pingsource-2
  id: 94cfefc6-57aa-471c-9ce5-1d8c61370c7e
  time: 2024-08-28T11:33:00.287533878Z
Extensions,
  knativearrivaltime: 2024-08-28T11:33:00.296630315Z
Data,
  {"message": "Hi from pingsource-2 from namespace-2"}

次に、OIDCを有効にします。

$ kubectl -n knative-eventing patch cm config-features --type merge --patch '{"data":{"authentication-oidc":"enabled"}}'

そして、次のEventPolicyを作成します。

apiVersion: eventing.knative.dev/v1alpha1
kind: EventPolicy
metadata:
  name: event-policy
  namespace: namespace-1
spec:
  to:
    - ref:
        apiVersion: eventing.knative.dev/v1
        kind: Broker
        name: broker
  from:
    - ref:
        apiVersion: sources.knative.dev/v1
        kind: PingSource
        name: pingsource-2
        namespace: namespace-2

その後、Brokerのステータスで、このEventPolicyが適用されたことを確認できます。

$ kubectl -n namespace-1 get broker broker -o yaml                                                                      
apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  name: broker
  namespace: namespace-1
  ...
spec:
  ...
status:
  ...
  conditions:
  ...
  - lastTransitionTime: "2024-08-28T11:53:48Z"
    status: "True"
    type: EventPoliciesReady
  - lastTransitionTime: "2024-08-28T11:26:16Z"
    status: "True"
    type: Ready

  policies:
  - apiVersion: eventing.knative.dev/v1alpha1
    name: event-policy

また、event-displayでは、Broker brokerにイベントを送信することを許可するために、EventPolicy event-policyで参照したため、pingsource-2からのイベントのみが表示されるはずです。

$ kubectl -n namespace-1 logs event-display-00001-deployment-56cd8dd644-64xl2
☁️  cloudevents.Event
Context Attributes,
  specversion: 1.0
  type: dev.knative.sources.ping
  source: /apis/v1/namespaces/namespace-2/pingsources/pingsource-2
  id: c0b4f5f2-5f95-4c0b-a3c6-6f61b6581a4b
  time: 2024-08-28T11:56:00.200782358Z
Extensions,
  knativearrivaltime: 2024-08-28T11:56:00.20834826Z
Data,
  {"message": "Hi from pingsource-2 from namespace-2"}
☁️  cloudevents.Event
Context Attributes,
  specversion: 1.0
  type: dev.knative.sources.ping
  source: /apis/v1/namespaces/namespace-2/pingsources/pingsource-2
  id: 6ab79fb0-2cf6-42a0-a43e-6bcd172558e5
  time: 2024-08-28T11:57:00.075390777Z
Extensions,
  knativearrivaltime: 2024-08-28T11:57:00.096497595Z
Data,
  {"message": "Hi from pingsource-2 from namespace-2"}

EventPolicyを削除し、OIDCを無効にしたままにすると、Brokerはデフォルトの認証モード（allow-same-namespace）に戻ります。

$ kubectl -n namespace-1 delete eventpolicy event-policy

これは、Brokerのステータスにも反映されるはずです。

$ kubectl -n namespace-1 get broker broker -o yaml           
apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  name: broker
  namespace: namespace-1
  ...
spec:
  ...
status:
  ...
  conditions:
  ...
  - lastTransitionTime: "2024-08-28T12:00:00Z"
    message: Default authz mode is "Allow-Same-Namespace
    reason: DefaultAuthorizationMode
    status: "True"
    type: EventPoliciesReady

  - lastTransitionTime: "2024-08-28T11:26:16Z"
    status: "True"
    type: Ready

そして、pingsource-1はbrokerと同じ名前空間にあるため、event-displayにpingsource-1からのイベントのみが表示されるはずです。

$ kubectl -n namespace-1 logs event-display-00001-deployment-56cd8dd644-64xl2
☁️  cloudevents.Event
Context Attributes,
  specversion: 1.0
  type: dev.knative.sources.ping
  source: /apis/v1/namespaces/namespace-1/pingsources/pingsource-1
  id: cd173aef-373a-4f2b-915e-43c138ac0602
  time: 2024-08-28T12:01:00.2504715Z
Extensions,
  knativearrivaltime: 2024-08-28T12:01:00.276151088Z
Data,
  {"message": "Hi from pingsource-1 from namespace-1"}
☁️  cloudevents.Event
Context Attributes,
  specversion: 1.0
  type: dev.knative.sources.ping
  source: /apis/v1/namespaces/namespace-1/pingsources/pingsource-1
  id: 22665003-fe81-4203-8896-89594077ae6b
  time: 2024-08-28T12:02:00.121025501Z
Extensions,
  knativearrivaltime: 2024-08-28T12:02:00.13378992Z
Data,
  {"message": "Hi from pingsource-1 from namespace-1"}

まとめ

Knative EventingのEventPolicyリソースは、イベント配信を安全に制御するための強力な方法を提供します。どのソースが特定のコンシューマーにイベントを送信できるかを定義することにより、ユーザーは、承認されたエンティティのみがイベント駆動型アーキテクチャ内で相互作用するようにできます。