Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

1.2. Service Mesh 2.x を使用して OpenShift Serverless でネットワークトラフィックを分離する

Service Mesh 2.x を OpenShift Serverless と併用して、サービス間のネットワークトラフィックを制御および分離できます。この統合により、きめ細かな通信ポリシーの定義、相互 TLS によるセキュリティーの強化、サーバーレス環境内のトラフィックフローの管理が可能になります。

重要

Service Mesh を使用して OpenShift Serverless でネットワークトラフィックを分離することは、テクノロジープレビューのみの機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

Service Mesh を使用すると、Service Mesh AuthorizationPolicy リソースを使用して、共有 Red Hat OpenShift Serverless クラスター上のテナント間のネットワークトラフィックを分離できます。Serverless では、いくつかの Service Mesh リソースを使用して、これを活用することもできます。テナントは、共有クラスター上のネットワークを介して相互にアクセスできる 1 つまたは複数のプロジェクトのグループです。

1.2.1. 前提条件
リンクのコピー

  • クラスター管理者アクセス権を持つ Red Hat OpenShift Serverless アカウントにアクセスできる。
  • Service Mesh 2.x と Serverless の統合がセットアップされている。
  • 各テナントに対して 1 つ以上の OpenShift プロジェクトを作成している。

1.2.2. 高レベルのアーキテクチャー
リンクのコピー

Service Mesh によって提供される Serverless トラフィック分離の高レベルアーキテクチャーは、knative-serving、knative-eventing、およびテナントの namespace 内の AuthorizationPolicy オブジェクトで構成され、すべてのコンポーネントは Service Mesh の一部です。注入された Service Mesh サイドカーは、これらのルールを強制して、テナント間のネットワークトラフィックを分離します。

1.2.3. Service Mesh の保護
リンクのコピー

認可ポリシーと mTLS により、Service Mesh を保護できます。

手順

  1. テナントのすべての Red Hat OpenShift Serverless プロジェクトがメンバーとして同じ ServiceMeshMemberRoll オブジェクトの一部であることを確認します。 

    apiVersion: maistra.io/v1
kind: ServiceMeshMemberRoll
metadata:
 name: default
 namespace: istio-system
spec:
 members:
   - knative-serving    # static value, needs to be here, see setup page
   - knative-eventing   # static value, needs to be here, see setup page
   - team-alpha-1       # example OpenShift project that belongs to the team-alpha tenant
   - team-alpha-2       # example OpenShift project that belongs th the team-alpha tenant
   - team-bravo-1       # example OpenShift project that belongs to the team-bravo tenant
   - team-bravo-2       # example OpenShift project that belongs th the team-bravo tenant

    メッシュの一部であるすべてのプロジェクトは、mTLS を厳密モードで強制する必要があります。これにより、Istio はクライアント証明書が存在する接続のみを受け入れるようになり、Service Mesh サイドカーが AuthorizationPolicy オブジェクトを使用して接続元を検証できるようになります。

  2. knative-serving および knative-eventing namespace に AuthorizationPolicy オブジェクトを使用して設定を作成します。

    knative-default-authz-policies.yaml 設定ファイルの例

    apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all-by-default
  namespace: knative-eventing
spec: { }
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all-by-default
  namespace: knative-serving
spec: { }
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-mt-channel-based-broker-ingress-to-imc-dispatcher
  namespace: knative-eventing
spec:
  action: ALLOW
  selector:
    matchLabels:
      app.kubernetes.io/component: "imc-dispatcher"
  rules:
    - from:
        - source:
            namespaces: [ "knative-eventing" ]
            principals: [ "cluster.local/ns/knative-eventing/sa/mt-broker-ingress" ]
      to:
        - operation:
            methods: [ "POST" ]
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-mt-channel-based-broker-ingress-to-kafka-channel
  namespace: knative-eventing
spec:
  action: ALLOW
  selector:
    matchLabels:
      app.kubernetes.io/component: "kafka-channel-receiver"
  rules:
    - from:
        - source:
            namespaces: [ "knative-eventing" ]
            principals: [ "cluster.local/ns/knative-eventing/sa/mt-broker-ingress" ]
      to:
        - operation:
            methods: [ "POST" ]
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-kafka-channel-to-mt-channel-based-broker-filter
  namespace: knative-eventing
spec:
  action: ALLOW
  selector:
    matchLabels:
      app.kubernetes.io/component: "broker-filter"
  rules:
    - from:
        - source:
            namespaces: [ "knative-eventing" ]
            principals: [ "cluster.local/ns/knative-eventing/sa/knative-kafka-channel-data-plane" ]
      to:
        - operation:
            methods: [ "POST" ]
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-imc-to-mt-channel-based-broker-filter
  namespace: knative-eventing
spec:
  action: ALLOW
  selector:
    matchLabels:
      app.kubernetes.io/component: "broker-filter"
  rules:
    - from:
        - source:
            namespaces: [ "knative-eventing" ]
            principals: [ "cluster.local/ns/knative-eventing/sa/imc-dispatcher" ]
      to:
        - operation:
            methods: [ "POST" ]
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-probe-kafka-broker-receiver
  namespace: knative-eventing
spec:
  action: ALLOW
  selector:
    matchLabels:
      app.kubernetes.io/component: "kafka-broker-receiver"
  rules:
    - from:
        - source:
            namespaces: [ "knative-eventing" ]
            principals: [ "cluster.local/ns/knative-eventing/sa/kafka-controller" ]
      to:
        - operation:
            methods: [ "GET" ]
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-probe-kafka-sink-receiver
  namespace: knative-eventing
spec:
  action: ALLOW
  selector:
    matchLabels:
      app.kubernetes.io/component: "kafka-sink-receiver"
  rules:
    - from:
        - source:
            namespaces: [ "knative-eventing" ]
            principals: [ "cluster.local/ns/knative-eventing/sa/kafka-controller" ]
      to:
        - operation:
            methods: [ "GET" ]
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-probe-kafka-channel-receiver
  namespace: knative-eventing
spec:
  action: ALLOW
  selector:
    matchLabels:
      app.kubernetes.io/component: "kafka-channel-receiver"
  rules:
    - from:
        - source:
            namespaces: [ "knative-eventing" ]
            principals: [ "cluster.local/ns/knative-eventing/sa/kafka-controller" ]
      to:
        - operation:
            methods: [ "GET" ]
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-traffic-to-activator
  namespace: knative-serving
spec:
  selector:
    matchLabels:
      app: activator
  action: ALLOW
  rules:
    - from:
        - source:
            namespaces: [ "knative-serving", "istio-system" ]
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-traffic-to-autoscaler
  namespace: knative-serving
spec:
  selector:
    matchLabels:
      app: autoscaler
  action: ALLOW
  rules:
    - from:
        - source:
            namespaces: [ "knative-serving" ]

    これらのポリシーは、Serverless システムコンポーネント間のネットワーク通信のアクセスルールを制限します。具体的には、次のルールが適用されます。

    • knative-serving および knative-eventing namespace で明示的に許可されていないすべてのトラフィックを拒否します。
    • istio-system および knative-serving namespace からアクティベーターへのトラフィックを許可する
    • knative-serving namespace からオートスケーラーへのトラフィックを許可する
    • knative-eventing namespace で Apache Kafka コンポーネントの正常性プローブを許可する
    • knative-eventing namespace でチャネルベースのブローカーの内部トラフィックを許可する

  3. 認可ポリシー設定を適用します。 

    $ oc apply -f knative-default-authz-policies.yaml

  4. どの OpenShift プロジェクトが相互に通信できるかを定義します。この通信のために、テナントのすべての OpenShift プロジェクトには以下が必要です。

    • テナントのプロジェクトへの直接受信トラフィックを制限する 1 つの AuthorizationPolicy オブジェクト
    • knative-serving プロジェクトで実行する Serverless のアクティベータコンポーネントを使用して受信トラフィックを制限する 1 つの AuthorizationPolicy オブジェクト
    • Kubernetes が Knative Services で PreStopHooks を呼び出すことを許可する 1 つの AuthorizationPolicy オブジェクト

    これらのポリシーを手動で作成する代わりに、helm ユーティリティーをインストールし、各テナントに必要なリソースを作成します。

    helm ユーティリティーのインストール

    $ helm repo add openshift-helm-charts https://charts.openshift.io/

    team alpha 用のサンプル設定の作成

    $ helm template openshift-helm-charts/redhat-knative-istio-authz --version 1.36.0 --set "name=team-alpha" --set "namespaces={team-alpha-1,team-alpha-2}" > team-alpha.yaml

    team bravo の設定例の作成

    $ helm template openshift-helm-charts/redhat-knative-istio-authz --version 1.31.0 --set "name=team-bravo" --set "namespaces={team-bravo-1,team-bravo-2}" > team-bravo.yaml

  5. 認可ポリシー設定を適用します。 

    $ oc apply -f team-alpha.yaml team-bravo.yaml

1.2.4. 設定の確認
リンクのコピー

curl コマンドを使用して、ネットワークトラフィック分離の設定を確認できます。

注記

次の例では、2 つのテナントがあり、それぞれが 1 つの namespace を持ち、ServiceMeshMemberRoll オブジェクトのすべての部分が、team-alpha.yaml ファイルおよび team-bravo.yaml ファイル内のリソースで設定されていると想定しています。

手順

  1. 両方のテナントの namespace に Knative Services をデプロイします。

    team-alpha のコマンド例

    $ kn service create test-webapp -n team-alpha-1 \
    --annotation-service serving.knative.openshift.io/enablePassthrough=true \
    --annotation-revision sidecar.istio.io/inject=true \
    --env RESPONSE="Hello Serverless" \
    --image docker.io/openshift/hello-openshift

    team-bravo のコマンド例

    $ kn service create test-webapp -n team-bravo-1 \
    --annotation-service serving.knative.openshift.io/enablePassthrough=true \
    --annotation-revision sidecar.istio.io/inject=true \
    --env RESPONSE="Hello Serverless" \
    --image docker.io/openshift/hello-openshift

    あるいは、次の YAML 設定を使用します。 

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: test-webapp
  namespace: team-alpha-1
  annotations:
    serving.knative.openshift.io/enablePassthrough: "true"
spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: 'true'
    spec:
      containers:
        - image: docker.io/openshift/hello-openshift
          env:
            - name: RESPONSE
              value: "Hello Serverless!"
---
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: test-webapp
  namespace: team-bravo-1
  annotations:
    serving.knative.openshift.io/enablePassthrough: "true"
spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: 'true'
    spec:
      containers:
        - image: docker.io/openshift/hello-openshift
          env:
            - name: RESPONSE
              value: "Hello Serverless!"

  2. 接続をテストするために curl Pod をデプロイします。 

    $ cat <<EOF | oc apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: curl
  namespace: team-alpha-1
  labels:
    app: curl
spec:
  replicas: 1
  selector:
    matchLabels:
      app: curl
  template:
    metadata:
      labels:
        app: curl
      annotations:
        sidecar.istio.io/inject: 'true'
    spec:
      containers:
      - name: curl
        image: curlimages/curl
        command:
        - sleep
        - "3600"
EOF

  3. curl コマンドを使用して設定を確認します。

    許可されているクラスターのローカルドメインを介して team-alpha-1 team-alpha-1 をテストします。

    コマンドの例

    $ oc exec deployment/curl -n team-alpha-1 -it -- curl -v http://test-webapp.team-alpha-1:80

    出力例

    HTTP/1.1 200 OK
content-length: 18
content-type: text/plain; charset=utf-8
date: Wed, 26 Jul 2023 12:49:59 GMT
server: envoy
x-envoy-upstream-service-time: 9

Hello Serverless!

    許可されている外部ドメインを介して team-alpha-1 から team-alpha-1 への接続をテストします。

    コマンドの例

    $ EXTERNAL_URL=$(oc get ksvc -n team-alpha-1 test-webapp -o custom-columns=:.status.url --no-headers) && \
oc exec deployment/curl -n team-alpha-1 -it -- curl -ik $EXTERNAL_URL

    出力例

    HTTP/2 200
content-length: 18
content-type: text/plain; charset=utf-8
date: Wed, 26 Jul 2023 12:55:30 GMT
server: istio-envoy
x-envoy-upstream-service-time: 3629

Hello Serverless!

    クラスターのローカルドメインを介して team-alpha-1 から team-bravo-1 への接続をテストしますが、これは許可されていません。

    コマンドの例

    $ oc exec deployment/curl -n team-alpha-1 -it -- curl -v http://test-webapp.team-bravo-1:80

    出力例

    * processing: http://test-webapp.team-bravo-1:80
*   Trying 172.30.73.216:80...
* Connected to test-webapp.team-bravo-1 (172.30.73.216) port 80
> GET / HTTP/1.1
> Host: test-webapp.team-bravo-1
> User-Agent: curl/8.2.0
> Accept: */*
>
< HTTP/1.1 403 Forbidden
< content-length: 19
< content-type: text/plain
< date: Wed, 26 Jul 2023 12:55:49 GMT
< server: envoy
< x-envoy-upstream-service-time: 6
<
* Connection #0 to host test-webapp.team-bravo-1 left intact
RBAC: access denied

    許可されている外部ドメインを介して、team-alpha-1 から team-bravo-1 への接続をテストします。

    コマンドの例

    $ EXTERNAL_URL=$(oc get ksvc -n team-bravo-1 test-webapp -o custom-columns=:.status.url --no-headers) && \
oc exec deployment/curl -n team-alpha-1 -it -- curl -ik $EXTERNAL_URL

    出力例

    HTTP/2 200
content-length: 18
content-type: text/plain; charset=utf-8
date: Wed, 26 Jul 2023 12:56:22 GMT
server: istio-envoy
x-envoy-upstream-service-time: 2856

Hello Serverless!

  4. 検証用に作成されたリソースを削除します。 

    $ oc delete deployment/curl -n team-alpha-1 && \
oc delete ksvc/test-webapp -n team-alpha-1 && \
oc delete ksvc/test-webapp -n team-bravo-1
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

Legal Notice

Theme

© 2026 Red Hatトップに戻る