ネットワーク

1. tls.crt および tls.key ファイルを使用して、カスタム証明書を含む Secret リソースを openshift-ingress namespace に作成します。

   $ oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key

2. IngressController CR を、新規証明書シークレットを参照するように更新します。

   $ oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \
     --patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'

3. 更新が正常に行われていることを確認します。

   $ echo Q |\
     openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null |\
     openssl x509 -noout -subject -issuer -enddate

   ここでは、以下のようになります。

   <domain>

   クラスターのベースドメイン名を指定します。

   出力例

   subject=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = *.apps.example.com
   issuer=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = example.com
   notAfter=May 10 08:32:45 2022 GM

   ヒント

   または、以下の YAML を適用してカスタムのデフォルト証明書を設定できます。

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: default
     namespace: openshift-ingress-operator
   spec:
     defaultCertificate:
       name: custom-certs-default

   証明書シークレットの名前は、CR を更新するために使用された値に一致する必要があります。

手順

1. 以下のコマンドを実行して、Thanos で認証するためのサービスアカウントを作成します。

   $ oc create -n openshift-ingress-operator serviceaccount thanos && oc describe -n openshift-ingress-operator serviceaccount thanos

   出力例

   Name:                thanos
   Namespace:           openshift-ingress-operator
   Labels:              <none>
   Annotations:         <none>
   Image pull secrets:  thanos-dockercfg-kfvf2
   Mountable secrets:   thanos-dockercfg-kfvf2
   Tokens:              <none>
   Events:              <none>

2. 次のコマンドを使用して、サービスアカウントシークレットトークンを手動で作成します。

   $ oc apply -f - <<EOF
   apiVersion: v1
   kind: Secret
   metadata:
     name: thanos-token
     namespace: openshift-ingress-operator
     annotations:
       kubernetes.io/service-account.name: thanos
   type: kubernetes.io/service-account-token
   EOF

3. サービスアカウントのトークンを使用して、openshift-ingress-operator namespace 内で TriggerAuthentication オブジェクトを定義します。

   1. TriggerAuthentication オブジェクトを作成し、secret 変数の値を TOKEN パラメーターに渡します。

      $ oc apply -f - <<EOF
      apiVersion: keda.sh/v1alpha1
      kind: TriggerAuthentication
      metadata:
        name: keda-trigger-auth-prometheus
        namespace: openshift-ingress-operator
      spec:
        secretTargetRef:
        - parameter: bearerToken
          name: thanos-token
          key: token
        - parameter: ca
          name: thanos-token
          key: ca.crt
      EOF

4. Thanos からメトリクスを読み取るためのロールを作成して適用します。

   1. Pod およびノードからメトリクスを読み取る新規ロール thanos-metrics-reader.yaml を作成します。

      thanos-metrics-reader.yaml

      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: thanos-metrics-reader
        namespace: openshift-ingress-operator
      rules:
      - apiGroups:
        - ""
        resources:
        - pods
        - nodes
        verbs:
        - get
      - apiGroups:
        - metrics.k8s.io
        resources:
        - pods
        - nodes
        verbs:
        - get
        - list
        - watch
      - apiGroups:
        - ""
        resources:
        - namespaces
        verbs:
        - get

   2. 以下のコマンドを実行して新規ロールを適用します。

      $ oc apply -f thanos-metrics-reader.yaml

5. 以下のコマンドを入力して、新しいロールをサービスアカウントに追加します。

   $ oc adm policy -n openshift-ingress-operator add-role-to-user thanos-metrics-reader -z thanos --role-namespace=openshift-ingress-operator

   $ oc adm policy -n openshift-ingress-operator add-cluster-role-to-user cluster-monitoring-view -z thanos

   注記

   引数 add-cluster-role-to-user は、namespace 間のクエリーを使用する場合にのみ必要になります。以下の手順では、この引数を必要とする kube-metrics namespace からのクエリーを使用します。

6. デフォルトの Ingress Controller デプロイメントをターゲットにする新しい ScaledObject YAML ファイル ingress-autoscaler.yaml を作成します。

   ScaledObject 定義の例

   apiVersion: keda.sh/v1alpha1
   kind: ScaledObject
   metadata:
     name: ingress-scaler
     namespace: openshift-ingress-operator
   spec:
     scaleTargetRef: 1
       apiVersion: operator.openshift.io/v1
       kind: IngressController
       name: default
       envSourceContainerName: ingress-operator
     minReplicaCount: 1
     maxReplicaCount: 20 2
     cooldownPeriod: 1
     pollingInterval: 1
     triggers:
     - type: prometheus
       metricType: AverageValue
       metadata:
         serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9091 3
         namespace: openshift-ingress-operator 4
         metricName: 'kube-node-role'
         threshold: '1'
         query: 'sum(kube_node_role{role="worker",service="kube-state-metrics"})' 5
         authModes: "bearer"
       authenticationRef:
         name: keda-trigger-auth-prometheus

   1

   対象とするカスタムリソース。この場合、Ingress Controller。

   2

   オプション: レプリカの最大数。このフィールドを省略すると、デフォルトの最大値は 100 レプリカに設定されます。

   3

   openshift-monitoring namespace の Thanos サービスエンドポイント。

   4

   Ingress Operator namespace。

   5

   この式は、デプロイされたクラスターに存在するワーカーノードの数に対して評価されます。

   重要

   namespace 間クエリーを使用している場合は、serverAddress フィールドのポート 9092 ではなくポート 9091 をターゲットにする必要があります。また、このポートからメトリクスを読み取るには、昇格した権限が必要です。

7. 以下のコマンドを実行してカスタムリソース定義を適用します。

   $ oc apply -f ingress-autoscaler.yaml

手順

1. デフォルト IngressController の現在の利用可能なレプリカ数を表示します。

   $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'

   出力例

   2

2. oc patch コマンドを使用して、デフォルトの IngressController を必要なレプリカ数にスケーリングします。以下の例では、デフォルトの IngressController を 3 つのレプリカにスケーリングしています。

   $ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=merge

   出力例

   ingresscontroller.operator.openshift.io/default patched

3. デフォルトの IngressController が指定したレプリカ数にスケーリングされていることを確認します。

   $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'

   出力例

   3

   ヒント

   または、以下の YAML を適用して Ingress Controller を 3 つのレプリカにスケーリングすることもできます。

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: default
     namespace: openshift-ingress-operator
   spec:
     replicas: 3               1

   1

   異なる数のレプリカが必要な場合は replicas 値を変更します。

手順

1. 以下の例のように、<name>-ingress-controller.yaml という名前のファイルに IngressController カスタムリソース (CR) を作成します。

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     namespace: openshift-ingress-operator
     name: <name> 1
   spec:
     domain: <domain> 2
     endpointPublishingStrategy:
       type: LoadBalancerService
       loadBalancer:
         scope: Internal 3

   1

   <name> を IngressController オブジェクトの名前に置き換えます。

   2

   コントローラーによって公開されるアプリケーションの ドメイン を指定します。

   3

   内部ロードバランサーを使用するために Internal の値を指定します。

2. 以下のコマンドを実行して、直前の手順で定義された Ingress Controller を作成します。

   $ oc create -f <name>-ingress-controller.yaml 1

   1

   <name> を IngressController オブジェクトの名前に置き換えます。

3. オプション: 以下のコマンドを実行して Ingress Controller が作成されていることを確認します。

   $ oc --all-namespaces=true get ingresscontrollers

手順

1. 削除や再作成を実行して、クラスターを内部に配置するように default Ingress Controller を設定します。

   $ oc replace --force --wait --filename - <<EOF
   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     namespace: openshift-ingress-operator
     name: default
   spec:
     endpointPublishingStrategy:
       type: LoadBalancerService
       loadBalancer:
         scope: Internal
   EOF

手順

1. ワイルドカードポリシーを設定します。

   1. 以下のコマンドを使用して IngressController リソースを編集します。

      $ oc edit IngressController

   2. spec の下で、wildcardPolicy フィールドを WildcardsDisallowed または WildcardsAllowed に設定します。

      spec:
        routeAdmission:
          wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed

手順

1. Ingress Controller リソースを編集します。

   $ oc -n openshift-ingress-operator edit ingresscontroller/default

2. X-SSL-Client-Der HTTP リクエストヘッダーは X-Forwarded-Client-Cert HTTP リクエストヘッダーに置き換えます。

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: default
     namespace: openshift-ingress-operator
   spec:
     httpHeaders:
       actions: 1
         request: 2
         - name: X-Forwarded-Client-Cert 3
           action:
             type: Set 4
             set:
              value: "%{+Q}[ssl_c_der,base64]" 5
         - name: X-SSL-Client-Der
           action:
             type: Delete

   1

   HTTP ヘッダーに対して実行するアクションのリスト。

   2

   変更するヘッダーのタイプ。この場合はリクエストヘッダーです。

   3

   変更するヘッダーの名前。設定または削除できる使用可能なヘッダーのリストは、HTTP ヘッダーの設定 を参照してください。

   4

   ヘッダーに対して実行されるアクションのタイプ。このフィールドには、Set または Delete の値を指定できます。

   5

   HTTP ヘッダーの設定時は、値 を指定する必要があります。値は、そのヘッダーで使用可能なディレクティブのリストからの文字列 (例: DENY) にすることも、HAProxy の動的値構文を使用して解釈される動的値にすることもできます。この場合、動的な値が追加されます。

   注記

   HTTP 応答の動的ヘッダー値を設定する場合、サンプルフェッチャーとして res.hdr および ssl_c_der を使用できます。HTTP リクエストの動的ヘッダー値を設定する場合、許可されるサンプルフェッチャーは req.hdr および ssl_c_der です。リクエストとレスポンスの両方の動的値で、lower コンバーターと Base64 コンバーターを使用できます。

3. 変更を適用するためにファイルを保存します。

手順

1. Ingress Controller 用に HTTPHeaders フィールドを設定します。

   1. 以下のコマンドを使用して IngressController リソースを編集します。

      $ oc edit IngressController

   2. spec の下で、HTTPHeaders ポリシーフィールドを Append、Replace、IfNone、または Never に設定します。

      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        httpHeaders:
          forwardedHeaderPolicy: Append

手順

1. CLI で次のコマンドを入力して、Ingress Controller リソースを編集します。

   $ oc -n openshift-ingress-operator edit ingresscontroller/default

2. PROXY 設定を設定します。

   • Ingress Controller が HostNetwork エンドポイント公開ストラテジータイプを使用する場合は、spec.endpointPublishingStrategy.hostNetwork.protocol サブフィールドを PROXY に設定します。

     PROXY への hostNetwork の設定例

     # ...
       spec:
         endpointPublishingStrategy:
           hostNetwork:
             protocol: PROXY
           type: HostNetwork
     # ...

   • Ingress Controller が NodePortService エンドポイント公開ストラテジータイプを使用する場合は、spec.endpointPublishingStrategy.nodePort.protocol サブフィールドを PROXY に設定します。

     PROXY へのサンプル nodePort 設定

     # ...
       spec:
         endpointPublishingStrategy:
           nodePort:
             protocol: PROXY
           type: NodePortService
     # ...

   • Ingress Controller が Private エンドポイント公開ストラテジータイプを使用する場合は、spec.endpointPublishingStrategy.private.protocol サブフィールドを PROXY に設定します。

     PROXY への private 設定のサンプル

     # ...
       spec:
         endpointPublishingStrategy:
           private:
             protocol: PROXY
         type: Private
     # ...

手順

1. ユーザーが作成するルートに代替のデフォルトドメインを指定して appsDomain フィールドを設定します。

   1. Ingress cluster リソースを編集します。

      $ oc edit ingresses.config/cluster -o yaml

   2. YAML ファイルを編集します。

      test.example.com への appsDomain の設定例

      apiVersion: config.openshift.io/v1
      kind: Ingress
      metadata:
        name: cluster
      spec:
        domain: apps.example.com            1
        appsDomain: <test.example.com>      2

      1

      デフォルトドメインを指定します。インストール後にデフォルトドメインを変更することはできません。

      2

      オプション: アプリケーションルートに使用する Red Hat OpenShift Service on AWS インフラストラクチャーのドメイン。デフォルトの接頭辞である apps の代わりに、test のような別の接頭辞を使用できます。

2. ルートを公開し、ルートドメインの変更を確認して、既存のルートに、appsDomain フィールドで指定したドメイン名が含まれていることを確認します。

   注記

   ルートを公開する前に openshift-apiserver がローリング更新を終了するのを待機します。

   1. ルートを公開します。

      $ oc expose service hello-openshift
      route.route.openshift.io/hello-openshift exposed

      出力例

      $ oc get routes
      NAME              HOST/PORT                                   PATH   SERVICES          PORT       TERMINATION   WILDCARD
      hello-openshift   hello_openshift-<my_project>.test.example.com
      hello-openshift   8080-tcp                 None

手順

1. Ingress Controller のhttpCompressionフィールドを設定します。

   1. 以下のコマンドを使用して IngressController リソースを編集します。

      $ oc edit -n openshift-ingress-operator ingresscontrollers/default

   2. specで、httpCompression ポリシーフィールドをmimeTypes に設定し、圧縮を適用する必要がある MIME タイプのリストを指定します。

      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        httpCompression:
          mimeTypes:
          - "text/html"
          - "text/css; charset=utf-8"
          - "application/json"
         ...

手順

1. 次のコマンドを実行して、ルーター Pod 名を取得します。

   $ oc get pods -n openshift-ingress

   出力例

   NAME                              READY   STATUS    RESTARTS   AGE
   router-default-76bfffb66c-46qwp   1/1     Running   0          11h

2. ルーター Pod が /var/lib/haproxy/conf/metrics-auth/statsUsername および /var/lib/haproxy/conf/metrics-auth/statsPassword ファイルに保存しているルーターのユーザー名およびパスワードを取得します。

   1. 次のコマンドを実行して、ユーザー名を取得します。

      $ oc rsh <router_pod_name> cat metrics-auth/statsUsername

   2. 次のコマンドを実行して、パスワードを取得します。

      $ oc rsh <router_pod_name> cat metrics-auth/statsPassword

3. 次のコマンドを実行して、ルーター IP およびメトリクス証明書を取得します。

   $ oc describe pod <router_pod>

4. つぎのコマンドを実行して、Prometheus 形式で未加工の統計情報を取得します。

   $ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics

5. 次のコマンドを実行して、安全にメトリクスにアクセスします。

   $ curl -u user:password https://<router_IP>:<stats_port>/metrics -k

6. 次のコマンドを実行して、デフォルトの stats ポート (1936) にアクセスします。

   $ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics

   例2.1 出力例

   ...
   # HELP haproxy_backend_connections_total Total number of connections.
   # TYPE haproxy_backend_connections_total gauge
   haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route"} 0
   haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route-alt"} 0
   haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route01"} 0
   ...
   # HELP haproxy_exporter_server_threshold Number of servers tracked and the current threshold value.
   # TYPE haproxy_exporter_server_threshold gauge
   haproxy_exporter_server_threshold{type="current"} 11
   haproxy_exporter_server_threshold{type="limit"} 500
   ...
   # HELP haproxy_frontend_bytes_in_total Current total of incoming bytes.
   # TYPE haproxy_frontend_bytes_in_total gauge
   haproxy_frontend_bytes_in_total{frontend="fe_no_sni"} 0
   haproxy_frontend_bytes_in_total{frontend="fe_sni"} 0
   haproxy_frontend_bytes_in_total{frontend="public"} 119070
   ...
   # HELP haproxy_server_bytes_in_total Current total of incoming bytes.
   # TYPE haproxy_server_bytes_in_total gauge
   haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_no_sni",service=""} 0
   haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_sni",service=""} 0
   haproxy_server_bytes_in_total{namespace="default",pod="docker-registry-5-nk5fz",route="docker-registry",server="10.130.0.89:5000",service="docker-registry"} 0
   haproxy_server_bytes_in_total{namespace="default",pod="hello-rc-vkjqx",route="hello-route",server="10.130.0.90:8080",service="hello-svc-1"} 0
   ...

7. ブラウザーで以下の URL を入力して、stats ウィンドウを起動します。

   http://<user>:<password>@<router_IP>:<stats_port>

8. オプション: ブラウザーに次の URL を入力して、CSV 形式で統計情報を取得します。

   http://<user>:<password>@<router_ip>:1936/metrics;csv

手順

1. openshift-config に my-custom-error-code-pages という名前の config map を作成します。

   $ oc -n openshift-config create configmap my-custom-error-code-pages \
   --from-file=error-page-503.http \
   --from-file=error-page-404.http

   重要

   カスタムエラーコードの応答ページに適した形式を指定しない場合は、ルーター Pod が停止します。この停止を解決するには、config map を削除するか、修正し、影響を受けるルーター Pod を削除して、正しい情報で再作成できるようにします。

2. Ingress Controller にパッチを適用し、名前を指定して my-custom-error-code-pages config map を参照します。

   $ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"httpErrorCodePages":{"name":"my-custom-error-code-pages"}}}' --type=merge

   Ingress Operator は、openshift-config namespace から openshift-ingress namespace に my-custom-error-code-pages config map をコピーします。Operator は、openshift-ingress namespace のパターン <your_ingresscontroller_name>-errorpages に従って config map に名前を付けます。

3. コピーを表示します。

   $ oc get cm default-errorpages -n openshift-ingress

   出力例

   NAME                       DATA   AGE
   default-errorpages         2      25s  1

   1

   default の Ingress Controller カスタムリソース (CR) にパッチが適用されているため、config map 名の例は default-errorpages です。

4. カスタムエラー応答ページを含む config map がルーターボリュームにマウントされることを確認します。config map キーは、カスタム HTTP エラーコード応答を持つファイル名です。

   • 503 カスタム HTTP カスタムエラーコード応答の場合:

     $ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-503.http

   • 404 カスタム HTTP カスタムエラーコード応答の場合:

     $ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-404.http

1. テストプロジェクトおよびアプリケーションを作成します。

    $ oc new-project test-ingress

   $ oc new-app django-psql-example

2. 503 カスタム http エラーコード応答の場合:

   1. アプリケーションのすべての Pod を停止します。

   2. 以下の curl コマンドを実行するか、ブラウザーでルートのホスト名にアクセスします。

      $ curl -vk <route_hostname>

3. 404 カスタム http エラーコード応答の場合:

   1. 存在しないルートまたは正しくないルートにアクセスします。

   2. 以下の curl コマンドを実行するか、ブラウザーでルートのホスト名にアクセスします。

      $ curl -vk <route_hostname>

4. errorfile 属性が haproxy.config ファイルで適切にあるかどうかを確認します。

   $ oc -n openshift-ingress rsh <router> cat /var/lib/haproxy/conf/haproxy.config | grep errorfile

手順

1. openshift-ingress-node-firewall namespace を作成するには、次のコマンドを入力します。

   $ cat << EOF| oc create -f -
   apiVersion: v1
   kind: Namespace
   metadata:
     labels:
       pod-security.kubernetes.io/enforce: privileged
       pod-security.kubernetes.io/enforce-version: v1.24
     name: openshift-ingress-node-firewall
   EOF

2. OperatorGroup CR を作成するには、以下のコマンドを実行します。

   $ cat << EOF| oc create -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: ingress-node-firewall-operators
     namespace: openshift-ingress-node-firewall
   EOF

3. Ingress Node Firewall Operator にサブスクライブします。

   1. Ingress Node Firewall Operator の Subscription CR を作成するには、次のコマンドを入力します。

      $ cat << EOF| oc create -f -
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: ingress-node-firewall-sub
        namespace: openshift-ingress-node-firewall
      spec:
        name: ingress-node-firewall
        channel: stable
        source: redhat-operators
        sourceNamespace: openshift-marketplace
      EOF

4. Operator がインストールされていることを確認するには、以下のコマンドを入力します。

   $ oc get ip -n openshift-ingress-node-firewall

   出力例

   NAME            CSV                                         APPROVAL    APPROVED
   install-5cvnz   ingress-node-firewall.4.0-202211122336   Automatic   true

5. Operator のバージョンを確認するには、次のコマンドを入力します。

   $ oc get csv -n openshift-ingress-node-firewall

   出力例

   NAME                                        DISPLAY                          VERSION               REPLACES                                    PHASE
   ingress-node-firewall.4.0-202211122336   Ingress Node Firewall Operator   4.0-202211122336   ingress-node-firewall.4.0-202211102047   Succeeded

手順

1. Ingress Node Firewall Operator をインストールします。

   1. Red Hat OpenShift Service on AWS Web コンソールで、Operator → OperatorHub をクリックします。
   2. 利用可能な Operator のリストから Ingress Node Firewall Operator を選択し、Install をクリックします。
   3. Install Operator ページの Installed Namespace で、Operator recommend Namespace を選択します。
   4. Install をクリックします。

2. Ingress Node Firewall Operator が正常にインストールされていることを確認します。

   1. Operators → Installed Operators ページに移動します。

   2. Ingress Node Firewall Operator が openshift-ingress-node-firewall プロジェクトにリストされ、Status が InstallSucceeded であることを確認します。

      注記

      インストール時に、Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。

      Operator の Status が InstallSucceeded でない場合は、次の手順を使用してトラブルシューティングを行います。

      • Operator Subscriptions および Install Plans タブで、Status の下の失敗またはエラーの有無を確認します。
      • Workloads → Pods ページに移動し、openshift-ingress-node-firewall プロジェクトの Pod のログを確認します。

      • YAML ファイルの namespace を確認してください。アノテーションが抜けている場合は、次のコマンドを使用して、アノテーションworkload.openshift.io/allowed=management を Operator namespace に追加できます。

        $ oc annotate ns/openshift-ingress-node-firewall workload.openshift.io/allowed=management

        注記

        単一ノードの OpenShift クラスターの場合、openshift-ingress-node-firewall namespace には workload.openshift.io/allowed=management アノテーションが必要です。

手順

1. OpenShift Cluster Manager で、アクセスするクラスターをクリックします。
2. コンソールを開く をクリックして、OpenShift Web コンソールに移動します。
3. アイデンティティープロバイダーをクリックし、クラスターにログインするためのクレデンシャルを指定します。
4. 管理者の観点から、Networking の下の NetworkPolicies をクリックします。
5. NetworkPolicy の作成 をクリックします。
6. ポリシー名 フィールドにポリシーの名前を入力します。
7. オプション: このポリシーが 1 つ以上の特定の Pod にのみ適用される場合は、特定の Pod のラベルとセレクターを指定できます。特定の Pod を選択しない場合、このポリシーはクラスター上のすべての Pod に適用されます。
8. オプション: Deny all ingress traffic または Deny all egress traffic チェックボックスを使用して、すべてのイングレストラフィックとエグレストラフィックをブロックできます。
9. イングレスルールとエグレスルールの任意の組み合わせを追加して、承認するポート、名前空間、または IP ブロックを指定することもできます。

10. Ingress ルールをポリシーに追加します。

    1. Add ingress rule を選択して新規ルールを設定します。このアクションにより、受信トラフィックを制限する方法を指定できる Add allowed source ドロップダウンメニューを含む新しい Ingress ルール 行が作成されます。ドロップダウンメニューでは、Ingress トラフィックを制限する 3 つのオプションを利用できます。

       • Allow pods from the same namespace では、空間内の Pod へのトラフィックが制限されます。namespace に Pod を指定できますが、このオプションは空のままにすると namespace の Pod からのすべてのトラフィックを許可します。
       • Allow pods from inside the cluster では、ポリシーと同じクラスター内の Pod へのトラフィックが制限されます。インバウンドトラフィックを許可する名前空間と Pod を指定できます。このオプションを空白のままにすると、このクラスター内のすべての名前空間と Pod からのインバウンドトラフィックが許可されます。
       • IP ブロックによるピアの許可 は、指定された Classless Inter-Domain Routing (CIDR) IP ブロックからのトラフィックを制限します。例外オプションを使用して、特定の IP をブロックできます。CIDR フィールドを空白のままにすると、すべての外部ソースからのすべてのインバウンドトラフィックが許可されます。
    2. すべての受信トラフィックをポートに制限できます。ポートを追加しない場合、トラフィックはすべてのポートにアクセスできます。

11. ネットワークポリシーにエグレスルールを追加します。

    1. Add egress rule 選択して、新しいルールを設定します。このアクションにより、送信トラフィックを制限する方法を指定できる Add allowed destination"* する * ドロップダウンメニューを含む新しい Egress rule 行が作成されます。ドロップダウンメニューには、下りトラフィックを制限する 3 つのオプションがあります。

       • Allow pods from the same namespace では、同じ namespace 内の Pod へのトラフィックが制限されます。namespace に Pod を指定できますが、このオプションは空のままにすると namespace の Pod からのすべてのトラフィックを許可します。
       • Allow pods from inside the cluster では、ポリシーと同じクラスター内の Pod へのトラフィックが制限されます。アウトバウンドトラフィックを許可する namespace および Pod を指定できます。このオプションを空白のままにすると、このクラスター内のすべての名前空間と Pod からのアウトバウンドトラフィックが許可されます。
       • Allow peers by IP block すると、指定された CIDR IP ブロックからのトラフィックが制限されます。例外オプションを使用して、特定の IP をブロックできます。CIDR フィールドを空白のままにすると、すべての外部ソースからのすべてのアウトバウンドが許可されます。
    2. すべてのアウトバウンドトラフィックをポートに制限できます。ポートを追加しない場合、トラフィックはすべてのポートにアクセスできます。

手順

1. OpenShift Cluster Manager Web コンソールの Administrator パースペクティブから、Networking の下にある NetworkPolicies をクリックします。
2. 表示するネットワークポリシーを選択します。
3. ネットワークポリシー の詳細ページで、関連付けられたすべての Ingress および egress ルールを表示できます。

4. ネットワークポリシーの詳細で YAML を選択して、ポリシー設定を YAML 形式で表示します。

   注記

   これらのポリシーの詳細のみを表示できます。これらのポリシーは編集できません。

手順

1. OpenShift Cluster Manager Web コンソールの Administrator パースペクティブから、Networking の下にある NetworkPolicies をクリックします。

2. ネットワークポリシーを削除するには、次のいずれかの方法を使用します。

   • ネットワークポリシー テーブルからポリシーを削除します。

     1. ネットワークポリシー テーブルから、削除するネットワークポリシーの行にあるスタックメニューを選択し、NetworkPolicy の削除 をクリックします。

   • 個々のネットワークポリシーの詳細から アクション ドロップダウンメニューを使用してポリシーを削除します。

     1. ネットワークポリシーの アクション ドロップダウンメニューをクリックします。
     2. メニューから Delete NetworkPolicy を選択します。

手順

1. cluster-admin 権限を持つユーザーとしてログインします。

2. デフォルトのプロジェクトテンプレートを生成します。

   $ oc adm create-bootstrap-project-template -o yaml > template.yaml

3. オブジェクトを追加するか、既存オブジェクトを変更することにより、テキストエディターで生成される template.yaml ファイルを変更します。

4. プロジェクトテンプレートは、openshift-config namespace に作成する必要があります。変更したテンプレートを読み込みます。

   $ oc create -f template.yaml -n openshift-config

5. Web コンソールまたは CLI を使用し、プロジェクト設定リソースを編集します。

   • Web コンソールの使用

     1. Administration → Cluster Settings ページに移動します。
     2. Configuration をクリックし、すべての設定リソースを表示します。
     3. Project のエントリーを見つけ、Edit YAML をクリックします。

   • CLI の使用

     1. project.config.openshift.io/cluster リソースを編集します。

        $ oc edit project.config.openshift.io/cluster

6. spec セクションを、projectRequestTemplate および name パラメーターを組み込むように更新し、アップロードされたプロジェクトテンプレートの名前を設定します。デフォルト名は project-request です。

   カスタムプロジェクトテンプレートを含むプロジェクト設定リソース

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
   # ...
   spec:
     projectRequestTemplate:
       name: <template_name>
   # ...

7. 変更を保存した後、変更が正常に適用されたことを確認するために、新しいプロジェクトを作成します。

手順

1. 以下のコマンドを実行して、新規プロジェクトのデフォルトテンプレートを編集します。

   $ oc edit template <project_template> -n openshift-config

   <project_template> を、クラスターに設定したデフォルトテンプレートの名前に置き換えます。デフォルトのテンプレート名は project-request です。

2. テンプレートでは、各 NetworkPolicy オブジェクトを要素として objects パラメーターに追加します。objects パラメーターは、1 つ以上のオブジェクトのコレクションを受け入れます。

   以下の例では、objects パラメーターのコレクションにいくつかの NetworkPolicy オブジェクトが含まれます。

   objects:
   - apiVersion: networking.k8s.io/v1
     kind: NetworkPolicy
     metadata:
       name: allow-from-same-namespace
     spec:
       podSelector: {}
       ingress:
       - from:
         - podSelector: {}
   - apiVersion: networking.k8s.io/v1
     kind: NetworkPolicy
     metadata:
       name: allow-from-openshift-ingress
     spec:
       ingress:
       - from:
         - namespaceSelector:
             matchLabels:
               network.openshift.io/policy-group: ingress
       podSelector: {}
       policyTypes:
       - Ingress
   - apiVersion: networking.k8s.io/v1
     kind: NetworkPolicy
     metadata:
       name: allow-from-kube-apiserver-operator
     spec:
       ingress:
       - from:
         - namespaceSelector:
             matchLabels:
               kubernetes.io/metadata.name: openshift-kube-apiserver-operator
           podSelector:
             matchLabels:
               app: kube-apiserver-operator
       policyTypes:
       - Ingress
   ...

3. オプション: 以下のコマンドを実行して、新規プロジェクトを作成し、ネットワークポリシーオブジェクトが正常に作成されることを確認します。

   1. 新規プロジェクトを作成します。

      $ oc new-project <project> 1

      1

      <project> を、作成しているプロジェクトの名前に置き換えます。

   2. 新規プロジェクトテンプレートのネットワークポリシーオブジェクトが新規プロジェクトに存在することを確認します。

      $ oc get networkpolicy
      NAME                           POD-SELECTOR   AGE
      allow-from-openshift-ingress   <none>         7s
      allow-from-same-namespace      <none>         7s

手順

1. 以下の NetworkPolicy オブジェクトを作成します。

   1. allow-from-openshift-ingress という名前のポリシー:

      $ cat << EOF| oc create -f -
      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-ingress
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                policy-group.network.openshift.io/ingress: ""
        podSelector: {}
        policyTypes:
        - Ingress
      EOF

      注記

      policy-group.network.openshift.io/Ingress: "" は、OVN-Kubernetes の推奨される namespace セレクターラベルです。

   2. allow-from-openshift-monitoring という名前のポリシー。

      $ cat << EOF| oc create -f -
      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-monitoring
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                network.openshift.io/policy-group: monitoring
        podSelector: {}
        policyTypes:
        - Ingress
      EOF

   3. allow-same-namespace という名前のポリシー:

      $ cat << EOF| oc create -f -
      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: allow-same-namespace
      spec:
        podSelector:
        ingress:
        - from:
          - podSelector: {}
      EOF

   4. allow-from-kube-apiserver-operator という名前のポリシー:

      $ cat << EOF| oc create -f -
      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-kube-apiserver-operator
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                kubernetes.io/metadata.name: openshift-kube-apiserver-operator
            podSelector:
              matchLabels:
                app: kube-apiserver-operator
        policyTypes:
        - Ingress
      EOF

      詳細は、新規の New kube-apiserver-operator webhook controller validating health of webhook を参照してください。

2. オプション: 以下のコマンドを実行し、ネットワークポリシーオブジェクトが現在のプロジェクトに存在することを確認します。

   $ oc describe networkpolicy

   出力例

   Name:         allow-from-openshift-ingress
   Namespace:    example1
   Created on:   2020-06-09 00:28:17 -0400 EDT
   Labels:       <none>
   Annotations:  <none>
   Spec:
     PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
     Allowing ingress traffic:
       To Port: <any> (traffic allowed to all ports)
       From:
         NamespaceSelector: network.openshift.io/policy-group: ingress
     Not affecting egress traffic
     Policy Types: Ingress
   
   
   Name:         allow-from-openshift-monitoring
   Namespace:    example1
   Created on:   2020-06-09 00:29:57 -0400 EDT
   Labels:       <none>
   Annotations:  <none>
   Spec:
     PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
     Allowing ingress traffic:
       To Port: <any> (traffic allowed to all ports)
       From:
         NamespaceSelector: network.openshift.io/policy-group: monitoring
     Not affecting egress traffic
     Policy Types: Ingress

検証

1. すべてのルートのアノテーションをクエリーするには、以下のコマンドを入力します。

   $ oc get route  --all-namespaces -o go-template='{{range .items}}{{if .metadata.annotations}}{{$a := index .metadata.annotations "haproxy.router.openshift.io/hsts_header"}}{{$n := .metadata.name}}{{with $a}}Name: {{$n}} HSTS: {{$a}}{{"\n"}}{{else}}{{""}}{{end}}{{end}}{{end}}'

   出力例

   Name: routename HSTS: max-age=0

手順

1. 指定される cookie 名でルートにアノテーションを付けます。

   $ oc annotate route <route_name> router.openshift.io/cookie_name="<cookie_name>"

   ここでは、以下のようになります。

   <route_name>

   Pod の名前を指定します。

   <cookie_name>

   cookie の名前を指定します。

   たとえば、ルート my_route に cookie 名 my_cookie でアノテーションを付けるには、以下を実行します。

   $ oc annotate route my_route router.openshift.io/cookie_name="my_cookie"

2. 変数でルートのホスト名を取得します。

   $ ROUTE_NAME=$(oc get route <route_name> -o jsonpath='{.spec.host}')

   ここでは、以下のようになります。

   <route_name>

   Pod の名前を指定します。

3. cookie を保存してからルートにアクセスします。

   $ curl $ROUTE_NAME -k -c /tmp/cookie_jar

   ルートに接続する際に、直前のコマンドによって保存される cookie を使用します。

   $ curl $ROUTE_NAME -k -b /tmp/cookie_jar