ネットワーク Operator
Red Hat OpenShift Service on AWS におけるネットワーク固有の Operator の管理
概要
第1章 AWS Load Balancer Operator リンクのコピーリンクがクリップボードにコピーされました!
AWS Load Balancer Operator は、Red Hat がサポートする Operator です。ユーザーは、これを SRE が管理する Red Hat OpenShift Service on AWS クラスターに必要に応じてインストールできます。
AWS Load Balancer Operator によって作成されたロードバランサーは、OpenShift ルート には使用できません。OpenShift ルートのレイヤー 7 機能をすべて必要としない個々のサービスまたは Ingress リソースにのみ使用する必要があります。
AWS Load Balancer Operator は、Red Hat OpenShift Service on AWS クラスターで AWS Load Balancer Controller をインストール、管理、および設定するために使用されます。
AWS Load Balancer Controller は、Kubernetes Ingress リソースを作成する際に AWS Application Load Balancers (ALB) をプロビジョニングし、LoadBalancer タイプを使用して Kubernetes Service リソースを作成する際に AWS Network Load Balancers (NLB) をプロビジョニングします。
デフォルトの AWS インツリーロードバランサープロバイダーと比較して、このコントローラーは ALB と NLB 用の詳細なアノテーションを使用して開発されています。高度な使用例としては以下が挙げられます。
- ネイティブ Kubernetes Ingress オブジェクトと ALB を使用する
- AWS ウェブアプリケーションファイアウォール (WAF) サービスと ALB を統合する
- カスタムの NLB ソース IP 範囲を指定する
- カスタムの NLB 内部 IP アドレスを指定する
1.1. AWS Load Balancer Operator のインストール準備 リンクのコピーリンクがクリップボードにコピーされました!
AWS Load Balancer Operator をインストールする前に、クラスターが要件を満たしていること、および AWS VPC リソースが適切にタグ付けされていることを確認してください。役立つ環境変数を設定するオプションもあります。
1.1.1. クラスターの要件 リンクのコピーリンクがクリップボードにコピーされました!
クラスターは、3 つのパブリックサブネットを持つ既存の VPC を使用して、3 つのアベイラビリティーゾーンにデプロイする必要があります。
これらの要件は、AWS Load Balancer Operator が一部の PrivateLink クラスターに適さない可能性があることを意味します。このようなクラスターには AWS NLB の方が適している可能性があります。
1.1.2. 一時的な環境変数のセットアップ リンクのコピーリンクがクリップボードにコピーされました!
リソース識別子と設定の詳細を保持するために、一時的な環境変数をセットアップするオプションがあります。一時環境変数を使用すると、AWS Load Balancer Operator のインストールコマンドを実行するプロセスが効率化されます。
特定の値を保存するために環境変数を使用しない場合は、関連するインストールコマンドにそれらの値を手動で入力できます。
前提条件
-
AWS CLI (
aws) をインストールしている。 -
OC CLI (
oc) がインストールされている。
手順
OpenShift CLI (
oc) を使用して、クラスター管理者としてクラスターにログインします。$ oc login --token=<token> --server=<cluster_url>環境変数をセットアップするには、次のコマンドを実行します。
$ export CLUSTER_NAME=$(oc get infrastructure cluster -o=jsonpath="{.status.apiServerURL}" | sed 's|^https://||' | awk -F . '{print $2}')$ export REGION=$(oc get infrastructure cluster -o=jsonpath="{.status.platformStatus.aws.region}")$ export OIDC_ENDPOINT=$(oc get authentication.config.openshift.io cluster -o jsonpath='{.spec.serviceAccountIssuer}' | sed 's|^https://||')$ export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)$ export SCRATCH="/tmp/${CLUSTER_NAME}/alb-operator"$ mkdir -p ${SCRATCH}これらのコマンドは、このターミナルセッションで使用してその値をコマンドラインインターフェイスに渡すことができる環境変数を作成します。
次のコマンドを実行して、変数値が正しく設定されていることを確認します。
$ echo "Cluster name: ${CLUSTER_NAME} Region: ${REGION} OIDC Endpoint: ${OIDC_ENDPOINT} AWS Account ID: ${AWS_ACCOUNT_ID}"出力例
Cluster name: <cluster_id> Region: <region> OIDC Endpoint: oidc.op1.openshiftapps.com/<oidc_id> AWS Account ID: <aws_id>
次のステップ
- 環境変数が失われないように、同じターミナルセッションを使用して AWS Load Balancer Operator のインストールを続行します。
1.1.3. AWS VPC とサブネットにタグを付ける リンクのコピーリンクがクリップボードにコピーされました!
AWS Load Balancer Operator をインストールする前に、AWS VPC リソースにタグを付ける必要があります。
前提条件
-
AWS CLI (
aws) をインストールしている。 -
OC CLI (
oc) がインストールされている。
手順
オプション: AWS VPC リソースの環境変数をセットアップします。
$ export VPC_ID=<vpc-id>$ export PUBLIC_SUBNET_IDS="<public-subnet-a-id> <public-subnet-b-id> <public-subnet-c-id>"$ export PRIVATE_SUBNET_IDS="<private-subnet-a-id> <private-subnet-b-id> <private-subnet-c-id>"VPC にタグを付けてクラスターに関連付けます。
$ aws ec2 create-tags --resources ${VPC_ID} --tags Key=kubernetes.io/cluster/${CLUSTER_NAME},Value=owned --region ${REGION}パブリックサブネットにタグを付けて、Elastic Load Balancing ロールによる変更を許可し、プライベートサブネットにタグを付けて、内部 Elastic Load Balancing ロールによる変更を許可します。
cat <<EOF > "${SCRATCH}/tag-subnets.sh" #!/bin/bash aws ec2 create-tags \ --resources ${PUBLIC_SUBNET_IDS} \ --tags Key=kubernetes.io/role/elb,Value='' \ --region ${REGION} aws ec2 create-tags \ --resources ${PRIVATE_SUBNET_IDS} \ --tags Key=kubernetes.io/role/internal-elb,Value='' \ --region ${REGION} EOFスクリプトを実行します。
bash ${SCRATCH}/tag-subnets.sh
関連情報
- 複数のアベイラビリティーゾーンで Red Hat OpenShift Service on AWS クラスターをセットアップするには、マルチ AZ Red Hat OpenShift Service on AWS クラスター を参照してください。
1.2. AWS Load Balancer Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift CLI (oc) を使用して AWS Load Balancer Operator をインストールできます。環境変数を活用するため、環境のセットアップで AWS Load Balancer Operator をインストール した際と同じターミナルセッションを使用します。
手順
AWS Load Balancer Operator 用にクラスター内に新しいプロジェクトを作成します。
$ oc new-project aws-load-balancer-operatorAWS Load Balancer Operator 用の AWS IAM ポリシーを作成します。
適切な IAM ポリシーをダウンロードします。
$ curl -o ${SCRATCH}/operator-permission-policy.json https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/refs/heads/main/hack/operator-permission-policy.jsonOperator の権限ポリシーを作成します。
$ aws iam create-policy \ --policy-name aws-load-balancer-operator-policy \ --policy-document file://${SCRATCH}/operator-permission-policy.json \ --region ${REGION}出力内の Operator ポリシー ARN をメモします。このプロセスの残りの部分では、これを
$OPERATOR_POLICY_ARNと呼びます。
AWS Load Balancer Operator の AWS IAM ロールを作成します。
Operator ロールの信頼ポリシーを作成します。
$ cat <<EOF > "${SCRATCH}/operator-trust-policy.json" { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Condition": { "StringEquals" : { "${OIDC_ENDPOINT}:sub": ["system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-operator-controller-manager", "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-controller-cluster"] } }, "Principal": { "Federated": "arn:aws:iam::${AWS_ACCOUNT_ID}:oidc-provider/${OIDC_ENDPOINT}" }, "Action": "sts:AssumeRoleWithWebIdentity" } ] } EOF信頼ポリシーを使用して Operator ロールを作成します。
$ aws iam create-role --role-name "${CLUSTER_NAME}-alb-operator" \ --assume-role-policy-document "file://${SCRATCH}/operator-trust-policy.json"出力内の Operator ロール ARN をメモします。このプロセスの残りの部分では、これを
$OPERATOR_ROLE_ARNと呼びます。Operator ロールとポリシーを関連付けます。
$ aws iam attach-role-policy --role-name "${CLUSTER_NAME}-alb-operator" \ --policy-arn $OPERATOR_POLICY_ARN
OperatorGroupとSubscriptionを作成して、AWS Load Balancer Operator をインストールします。$ cat <<EOF | oc apply -f - apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: aws-load-balancer-operator namespace: aws-load-balancer-operator spec: targetNamespaces: [] --- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: aws-load-balancer-operator namespace: aws-load-balancer-operator spec: channel: stable-v1 name: aws-load-balancer-operator source: redhat-operators sourceNamespace: openshift-marketplace config: env: - name: ROLEARN value: "${OPERATOR_ROLE_ARN}" EOFAWS Load Balancer Controller の AWS IAM ポリシーを作成します。
適切な IAM ポリシーをダウンロードします。
$ curl -o ${SCRATCH}/controller-permission-policy.json https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.12.0/docs/install/iam_policy.jsonController の権限ポリシーを作成します。
$ aws iam create-policy \ --region ${REGION} \ --policy-name aws-load-balancer-controller-policy \ --policy-document file://${SCRATCH}/controller-permission-policy.json出力内の Controller ポリシー ARN をメモします。このプロセスの残りの部分では、これを
$CONTROLLER_POLICY_ARNと呼びます。
AWS Load Balancer Controller 用の AWS IAM ロールを作成します。
Controller ロールの信頼ポリシーを作成します。
$ cat <<EOF > ${SCRATCH}/controller-trust-policy.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::${AWS_ACCOUNT_ID}:oidc-provider/${OIDC_ENDPOINT}" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "${OIDC_ENDPOINT}:sub": "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-controller-cluster" } } } ] } EOF信頼ポリシーを使用して Controller ロールを作成します。
CONTROLLER_ROLE_ARN=$(aws iam create-role --role-name "${CLUSTER_NAME}-albo-controller" \ --assume-role-policy-document "file://${SCRATCH}/controller-trust-policy.json" \ --query Role.Arn --output text) echo ${CONTROLLER_ROLE_ARN}出力内の Controller ロール ARN をメモします。このプロセスの残りの部分では、これを
$CONTROLLER_ROLE_ARNと呼びます。Controller のロールとポリシーを関連付けます。
$ aws iam attach-role-policy \ --role-name "${CLUSTER_NAME}-albo-controller" \ --policy-arn ${CONTROLLER_POLICY_ARN}
AWS Load Balancer Controller のインスタンスをデプロイします。
$ cat << EOF | oc apply -f - apiVersion: networking.olm.openshift.io/v1 kind: AWSLoadBalancerController metadata: name: cluster spec: credentialsRequestConfig: stsIAMRoleARN: ${CONTROLLER_ROLE_ARN} EOF注記ここでエラーが発生した場合は、少し待ってから再試行してください。エラーが発生するのは、Operator がまだインストールを完了していないためです。
Operator Pod と Controller Pod の両方が実行されていることを確認します。
$ oc -n aws-load-balancer-operator get pods次のような出力が表示されない場合は、しばらく待ってから再試行してください。
出力例
NAME READY STATUS RESTARTS AGE aws-load-balancer-controller-cluster-6ddf658785-pdp5d 1/1 Running 0 99s aws-load-balancer-operator-controller-manager-577d9ffcb9-w6zqn 2/2 Running 0 2m4s
1.3. Operator インストールの検証 リンクのコピーリンクがクリップボードにコピーされました!
基本的なサンプルアプリケーションをデプロイし、Ingress および負荷分散サービスを作成して、AWS Load Balancer Operator と Controller が正しくデプロイされていることを確認します。
手順
プロジェクトを新規作成します。
$ oc new-project hello-worldhello-openshiftイメージに基づいて新しいhello-worldアプリケーションを作成します。$ oc new-app -n hello-world --image=docker.io/openshift/hello-openshiftAWS Application Load Balancer (ALB) が接続するための
NodePortサービスを設定します。$ cat << EOF | oc apply -f - apiVersion: v1 kind: Service metadata: name: hello-openshift-nodeport namespace: hello-world spec: ports: - port: 80 targetPort: 8080 protocol: TCP type: NodePort selector: deployment: hello-openshift EOFアプリケーション用の AWS ALB をデプロイします。
$ cat << EOF | oc apply -f - apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: hello-openshift-alb namespace: hello-world annotations: alb.ingress.kubernetes.io/scheme: internet-facing spec: ingressClassName: alb rules: - http: paths: - path: / pathType: Exact backend: service: name: hello-openshift-nodeport port: number: 80 EOFアプリケーションの AWS ALB エンドポイントへのアクセスをテストします。
注記ALB のプロビジョニングには数分かかります。
curl: (6) Could not resolve hostというエラーが表示された場合は、待機してから再試行してください。$ ALB_INGRESS=$(oc -n hello-world get ingress hello-openshift-alb \ -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')$ curl "http://${ALB_INGRESS}"出力例
Hello OpenShift!アプリケーション用の AWS Network Load Balancer (NLB) をデプロイします。
$ cat << EOF | oc apply -f - apiVersion: v1 kind: Service metadata: name: hello-openshift-nlb namespace: hello-world annotations: service.beta.kubernetes.io/aws-load-balancer-type: external service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: instance service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing spec: ports: - port: 80 targetPort: 8080 protocol: TCP type: LoadBalancer selector: deployment: hello-openshift EOFアプリケーションの NLB エンドポイントへのアクセスをテストします。
注記NLB のプロビジョニングには数分かかります。
curl: (6) Could not resolve hostというエラーが表示された場合は、待機してから再試行してください。$ NLB=$(oc -n hello-world get service hello-openshift-nlb \ -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')$ curl "http://${NLB}"出力には
Hello OpenShift!と表示されるはずです。これで、サンプルアプリケーションと
hello-worldnamespace 内のすべてのリソースを削除できます。$ oc delete project hello-world
1.4. AWS Load Balancer Operator の削除 リンクのコピーリンクがクリップボードにコピーされました!
AWS Load Balancer Operator を使用する必要がなくなった場合は、Operator を削除し、関連するロールとポリシーを削除できます。
手順
Operator のサブスクリプションを削除します。
$ oc delete subscription aws-load-balancer-operator -n aws-load-balancer-operator関連する AWS IAM ロールをデタッチして削除します。
$ aws iam detach-role-policy \ --role-name "<cluster-id>-alb-operator" \ --policy-arn <operator-policy-arn>$ aws iam delete-role \ --role-name "<cluster-id>-alb-operator"AWS IAM ポリシーを削除します。
$ aws iam delete-policy --policy-arn <operator-policy-arn>
第2章 Red Hat OpenShift Service on AWS の DNS Operator リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS の DNS Operator は、CoreDNS インスタンスをデプロイおよび管理して、クラスター内の Pod に名前解決サービスを提供し、DNS ベースの Kubernetes Service 検出を有効にし、内部の cluster.local 名を解決します。
この Operator は、デフォルトで Red Hat OpenShift Service on AWS クラスターにインストールされています。
2.1. DNS 転送の使用 リンクのコピーリンクがクリップボードにコピーされました!
次の方法で、DNS 転送を使用して /etc/resolv.conf ファイル内のデフォルトの転送設定をオーバーライドできます。
すべてのゾーンにネームサーバー (
spec.servers) を指定します。転送されるゾーンが Red Hat OpenShift Service on AWS に管理される Ingress ドメインである場合は、アップストリームネームサーバーがドメインに対して認証される必要があります。重要少なくとも 1 つのゾーンを指定する必要があります。そうしないと、クラスターの機能が失われる可能性があります。
-
アップストリーム DNS サーバーのリスト (
spec.upstreamResolvers) を指定します。 - デフォルトの転送ポリシーを変更します。
デフォルトドメインの DNS 転送設定には、/etc/resolv.conf ファイルおよびアップストリーム DNS サーバーで指定されたデフォルトのサーバーの両方を設定できます。
手順
defaultという名前の DNS Operator オブジェクトを変更します。$ oc edit dns.operator/default上記のコマンドを実行すると、Operator が、
spec.serversに基づく追加のサーバー設定ブロックを使用してdns-defaultという名前の config map を作成および更新します。重要zonesパラメーターの値を指定する場合は、イントラネットなどの特定のゾーンにのみ転送してください。少なくとも 1 つのゾーンを指定する必要があります。そうしないと、クラスターの機能が失われる可能性があります。クエリーに一致するゾーンがサーバーにない場合には、名前解決はアップストリーム DNS サーバーにフォールバックします。
DNS 転送の設定
apiVersion: operator.openshift.io/v1 kind: DNS metadata: name: default spec: cache: negativeTTL: 0s positiveTTL: 0s logLevel: Normal nodePlacement: {} operatorLogLevel: Normal servers: - name: example-server1 zones: - example.com2 forwardPlugin: policy: Random3 upstreams:4 - 1.1.1.1 - 2.2.2.2:5353 upstreamResolvers:5 policy: Random6 protocolStrategy: ""7 transportConfig: {}8 upstreams: - type: SystemResolvConf9 - type: Network address: 1.2.3.410 port: 5311 status: clusterDomain: cluster.local clusterIP: x.y.z.10 conditions: ...- 1
rfc6335サービス名の構文に準拠する必要があります。- 2
rfc1123サービス名構文のサブドメインの定義に準拠する必要があります。クラスタードメインのcluster.localは、zonesフィールドの無効なサブドメインです。- 3
forwardPluginにリストされているアップストリームリゾルバーを選択するポリシーを定義します。デフォルト値はRandomです。RoundRobinおよびSequentialの値を使用することもできます。- 4
forwardPluginごとに最大 15 のupstreamsが許可されます。- 5
upstreamResolversを使用すると、デフォルトの転送ポリシーをオーバーライドし、デフォルトドメインの指定された DNS リゾルバー (アップストリームリゾルバー) に DNS 解決を転送できます。アップストリームリゾルバーを提供しなかった場合、DNS 名のクエリーが/etc/resolv.confで宣言されたサーバーに送信されます。- 6
upstreamsにリストされているアップストリームサーバーをクエリーのために選択する順序を決定します。Random、RoundRobin、またはSequentialのいずれかの値を指定できます。デフォルト値はSequentialです。- 7
- 省略すると、デフォルト (通常は元のクライアント要求のプロトコル) が選択されます。
TCPに設定すると、クライアント要求が UDP を使用する場合でも、すべてのアップストリーム DNS 要求に対して TCP が必ず使用されます。 - 8
- DNS 要求をアップストリームリゾルバーに転送するときに使用するトランスポートタイプ、サーバー名、およびオプションのカスタム CA または CA バンドルを設定するために使用されます。
- 9
- 2 種類の
upstreams(SystemResolvConfまたはNetwork) を指定できます。SystemResolvConfで、アップストリームが/etc/resolv.confを使用するように設定して、NetworkでNetworkresolverを定義します。1 つまたは両方を指定できます。 - 10
- 指定したタイプが
Networkの場合には、IP アドレスを指定する必要があります。addressフィールドは、有効な IPv4 または IPv6 アドレスである必要があります。 - 11
- 指定したタイプが
Networkの場合、必要に応じてポートを指定できます。portフィールドには1-65535の値を指定する必要があります。アップストリームのポートを指定しない場合、デフォルトのポートは 853 です。
第3章 Red Hat OpenShift Service on AWS の Ingress Operator リンクのコピーリンクがクリップボードにコピーされました!
Ingress Operator は IngressController API を実装し、Red Hat OpenShift Service on AWS クラスターサービスへの外部アクセスを可能にするコンポーネントです。
この Operator は、デフォルトで Red Hat OpenShift Service on AWS クラスターにインストールされています。
3.1. Red Hat OpenShift Service on AWS Ingress Operator リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS クラスターを作成すると、クラスターで実行されている Pod とサービスにそれぞれ独自の IP アドレスが割り当てられます。IP アドレスは、近くで実行されている他の Pod やサービスからアクセスできますが、外部クライアントの外部からはアクセスできません。
Ingress Operator を使用すると、ルーティングを処理する 1 つ以上の HAProxy ベースの Ingress Controller をデプロイおよび管理することにより、外部クライアントがサービスにアクセスできるようになります。
Red Hat Site Reliability Engineer (SRE) は、Red Hat OpenShift Service on AWS クラスターの Ingress Operator を管理します。Ingress Operator の設定を変更することはできませんが、デフォルトの Ingress Controller の設定、ステータス、およびログおよび Ingress Operator ステータスを表示できます。
3.2. デフォルト Ingress Controller の表示 リンクのコピーリンクがクリップボードにコピーされました!
Ingress Operator は Red Hat OpenShift Service on AWS のコア機能であり、すぐに有効にできます。
Red Hat OpenShift Service on AWS の新しいインストールにはすべて、default という名前の ingresscontroller があります。これは、追加の Ingress Controller で補足できます。デフォルトの ingresscontroller が削除される場合、Ingress Operator は 1 分以内にこれを自動的に再作成します。
手順
デフォルト Ingress Controller を表示します。
$ oc describe --namespace=openshift-ingress-operator ingresscontroller/default
3.3. Ingress Operator ステータスの表示 リンクのコピーリンクがクリップボードにコピーされました!
Ingress Operator のステータスを表示し、検査することができます。
手順
Ingress Operator ステータスを表示します。
$ oc describe clusteroperators/ingress
3.4. Ingress Controller ログの表示 リンクのコピーリンクがクリップボードにコピーされました!
Ingress Controller ログを表示できます。
手順
Ingress Controller ログを表示します。
$ oc logs --namespace=openshift-ingress-operator deployments/ingress-operator -c <container_name>
3.5. Ingress Controller ステータスの表示 リンクのコピーリンクがクリップボードにコピーされました!
特定の Ingress Controller のステータスを表示できます。
手順
Ingress Controller のステータスを表示します。
$ oc describe --namespace=openshift-ingress-operator ingresscontroller/<name>
3.6. default Ingress Controller 機能の管理 リンクのコピーリンクがクリップボードにコピーされました!
次の表は、Ingress Operator によって管理される default Ingress Controller のコンポーネントと、Red Hat Site Reliability Engineering (SRE) が Red Hat OpenShift Service on AWS クラスターでこのコンポーネントを管理するかどうかの詳細を示しています。
| Ingress コンポーネント | 管理 | デフォルト設定? |
|---|---|---|
| Ingress Controller のスケーリング | SRE | はい |
| Ingress Operator のスレッド数 | SRE | はい |
| Ingress Controller のアクセスロギング | SRE | はい |
| Ingress Controller のシャード化 | SRE | はい |
| Ingress Controller ルートの受付ポリシー | SRE | はい |
| Ingress Controller のワイルドカードルート | SRE | はい |
| Ingress Controller X-Forwarded ヘッダー | SRE | はい |
| Ingress Controller ルートの圧縮 | SRE | はい |
第4章 Red Hat OpenShift Service on AWS の Ingress Node Firewall Operator リンクのコピーリンクがクリップボードにコピーされました!
Ingress Node Firewall Operator は、Red Hat OpenShift Service on AWS でノードレベルの Ingress トラフィックを管理するための、ステートレスな eBPF ベースのファイアウォールを提供します。
4.1. Ingress Node Firewall Operator リンクのコピーリンクがクリップボードにコピーされました!
Ingress Node Firewall Operator は、ファイアウォール設定で指定および管理するノードにデーモンセットをデプロイすることにより、ノードレベルで Ingress ファイアウォールルールを提供します。デーモンセットをデプロイするには、IngressNodeFirewallConfig カスタムリソース (CR) を作成します。Operator は IngressNodeFirewallConfig CR を適用して、nodeSelector に一致するすべてのノードで実行される ingress ノードファイアウォールデーモンセット (daemon) を作成します。
IngressNodeFirewall CR の rules を設定し、nodeSelector を使用して値を "true" に設定してクラスターに適用します。
Ingress Node Firewall Operator は、ステートレスファイアウォールルールのみをサポートします。
ネイティブ XDP ドライバーをサポートしないネットワークインターフェイスコントローラー (NIC) は、より低いパフォーマンスで実行されます。
Ingress Node Firewall Operator は、Red Hat OpenShift Service on AWS 4.14 以降で実行する必要があります。
4.2. Ingress Node Firewall Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、Red Hat OpenShift Service on AWS CLI または Web コンソールを使用して Ingress Node Firewall Operator をインストールできます。
4.2.1. CLI を使用した Ingress Node Firewall Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、CLI を使用して Operator をインストールできます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - 管理者権限を持つアカウントがある。
手順
openshift-ingress-node-firewallnamespace を作成するには、次のコマンドを入力します。$ 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 EOFOperatorGroupCR を作成するには、以下のコマンドを実行します。$ cat << EOF| oc create -f - apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: ingress-node-firewall-operators namespace: openshift-ingress-node-firewall EOFIngress Node Firewall Operator にサブスクライブします。
Ingress Node Firewall Operator の
SubscriptionCR を作成するには、次のコマンドを入力します。$ 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
Operator がインストールされていることを確認するには、以下のコマンドを入力します。
$ oc get ip -n openshift-ingress-node-firewall出力例
NAME CSV APPROVAL APPROVED install-5cvnz ingress-node-firewall.4.0-202211122336 Automatic trueOperator のバージョンを確認するには、次のコマンドを入力します。
$ 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
4.2.2. Web コンソールを使用した Ingress Node Firewall Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、Web コンソールを使用して Operator をインストールできます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - 管理者権限を持つアカウントがある。
手順
Ingress Node Firewall Operator をインストールします。
- Red Hat OpenShift Service on AWS Web コンソールで、Ecosystem → Software Catalog をクリックします。
- 利用可能な Operator のリストから Ingress Node Firewall Operator を選択し、Install をクリックします。
- Install Operator ページの Installed Namespace で、Operator recommended Namespace を選択します。
- Install をクリックします。
Ingress Node Firewall Operator が正常にインストールされていることを確認します。
- Ecosystem → Installed Operators ページに移動します。
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-firewallnamespace にはworkload.openshift.io/allowed=managementアノテーションが必要です。
4.3. Ingress Node Firewall Operator のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
前提条件
- Ingress Node Firewall Operator がインストールされます。
手順
Ingress Node Firewall Operator をデプロイするには、Operator のデーモンセットをデプロイする IngressNodeFirewallConfig カスタムリソースを作成します。ファイアウォールルールを適用することで、1 つまたは複数の IngressNodeFirewall CRD をノードにデプロイできます。
-
ingressnodefirewallconfigという名前のopenshift-ingress-node-firewallnamespace 内にIngressNodeFirewallConfigを作成します。 次のコマンドを実行して、Ingress Node Firewall Operator ルールをデプロイします。
$ oc apply -f rule.yaml
4.3.1. Ingress ノードファイアウォール設定オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
Ingress Node Firewall 設定オブジェクトのフィールドについて、次の表で説明します。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
CR オブジェクトの名前。ファイアウォールルールオブジェクトの名前は |
|
|
|
Ingress Firewall Operator CR オブジェクトの namespace。 |
|
|
| 指定されたノードラベルを介してノードをターゲットにするために使用されるノード選択制約。以下に例を示します。
注記
デーモンセットを開始するには、 |
|
|
| Node Ingress Firewall Operator が eBPF プログラムを管理するために eBPF Manager Operator を使用するかどうかを指定します。この機能はテクノロジープレビュー機能です。 Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。 |
Operator はまず、すべてのノードでデーモンセットを生成するために、IngressNodeFirewallConfig を使用します。これを作成した後、追加のファイアウォールルールオブジェクトを作成できます。
4.3.2. Ingress Node Firewall Operator の設定例 リンクのコピーリンクがクリップボードにコピーされました!
次の例では、完全な Ingress ノードファイアウォール設定が指定されています。
Ingress ノードファイアウォール設定オブジェクトを作成する方法の例
$ cat << EOF | oc create -f -
apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewallConfig
metadata:
name: ingressnodefirewallconfig
namespace: openshift-ingress-node-firewall
spec:
nodeSelector:
node-role.kubernetes.io/worker: ""
EOF
Operator は CR オブジェクトを消費し、nodeSelector に一致するすべてのノードに Ingress ノードファイアウォールデーモンセットを作成します。
4.3.3. Ingress ノードファイアウォールルールオブジェクト リンクのコピーリンクがクリップボードにコピーされました!
Ingress ノードファイアウォールルールオブジェクトのフィールドについて、次の表で説明します。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| CR オブジェクトの名前。 |
|
|
|
このオブジェクトのフィールドは、ファイアウォールルールを適用するインターフェイスを指定します。たとえば、 |
|
|
|
|
|
|
|
|
4.3.3.1. Ingress オブジェクトの設定 リンクのコピーリンクがクリップボードにコピーされました!
ingress オブジェクトの値は、次の表で定義されています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| CIDR ブロックを設定できます。異なるアドレスファミリーから複数の CIDR を設定できます。 注記
異なる CIDR を使用すると、同じ順序ルールを使用できます。CIDR が重複する同じノードおよびインターフェイスに対して複数の |
|
|
|
Ingress ファイアウォール
注記 Ingress ファイアウォールルールは、無効な設定をブロックする検証 Webhook を使用して検証されます。検証 Webhook は、API サーバーなどの重大なクラスターサービスをブロックすることを防ぎます。 |
4.3.3.2. Ingress ノードファイアウォールルールオブジェクトの例 リンクのコピーリンクがクリップボードにコピーされました!
次の例では、完全な Ingress ノードファイアウォール設定が指定されています。
Ingress ノードファイアウォールの設定例
apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewall
metadata:
name: ingressnodefirewall
spec:
interfaces:
- eth0
nodeSelector:
matchLabels:
<ingress_firewall_label_name>: <label_value>
ingress:
- sourceCIDRs:
- 172.16.0.0/12
rules:
- order: 10
protocolConfig:
protocol: ICMP
icmp:
icmpType: 8 #ICMP Echo request
action: Deny
- order: 20
protocolConfig:
protocol: TCP
tcp:
ports: "8000-9000"
action: Deny
- sourceCIDRs:
- fc00:f853:ccd:e793::0/64
rules:
- order: 10
protocolConfig:
protocol: ICMPv6
icmpv6:
icmpType: 128 #ICMPV6 Echo request
action: Deny
- 1
- <label_name> と <label_value> はノード上に存在する必要があり、
ingressfirewallconfigCR を実行するノードに適用されるnodeselectorラベルと値に一致する必要があります。<label_value> は、trueまたはfalseです。nodeSelectorラベルを使用すると、ノードのグループを個別にターゲットにして、ingressfirewallconfigCR の使用に異なるルールを適用できます。
4.3.3.3. ゼロトラスト Ingress ノードファイアウォールルールオブジェクトの例 リンクのコピーリンクがクリップボードにコピーされました!
ゼロトラストの Ingress ノードファイアウォールルールは、マルチインターフェイスクラスターに追加のセキュリティーを提供できます。たとえば、ゼロトラストの Ingress ノードファイアウォールルールを使用して、SSH を除く特定のインターフェイス上のすべてのトラフィックをドロップできます。
次の例では、ゼロトラスト Ingress ノードファイアウォールルールセットの完全な設定が指定されています。
次の場合、ユーザーはアプリケーションが使用するすべてのポートを許可リストに追加して、適切な機能を確保する必要があります。
ゼロトラストの Ingress ノードファイアウォールルールの例
apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewall
metadata:
name: ingressnodefirewall-zero-trust
spec:
interfaces:
- eth1
nodeSelector:
matchLabels:
<ingress_firewall_label_name>: <label_value>
ingress:
- sourceCIDRs:
- 0.0.0.0/0
rules:
- order: 10
protocolConfig:
protocol: TCP
tcp:
ports: 22
action: Allow
- order: 20
action: Deny
eBPF Manager Operator の統合は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
4.4. Ingress ノードファイアウォール Operator の統合 リンクのコピーリンクがクリップボードにコピーされました!
Ingress Node Firewall は、eBPF プログラムを使用して、主要なファイアウォール機能の一部を実装します。デフォルトでは、これらの eBPF プログラムは、Ingress Node Firewall に固有のメカニズムを使用してカーネルにロードされます。代わりに、これらのプログラムのロードと管理に eBPF Manager Operator を使用するように Ingress Node Firewall Operator を設定できます。
この統合を有効にすると、次の制限が適用されます。
- XDP が利用できず、TCX が bpfman と互換性がない場合、Ingress Node Firewall Operator は TCX を使用します。
-
Ingress Node Firewall Operator デーモンセットの Pod は、ファイアウォールルールが適用されるまで
ContainerCreating状態のままになります。 - Ingress Node Firewall Operator デーモンセットの Pod は権限として実行します。
4.5. eBPF Manager Operator を使用するように Ingress ノードファイアウォール Operator の設定 リンクのコピーリンクがクリップボードにコピーされました!
Ingress Node Firewall は、eBPF プログラムを使用して、主要なファイアウォール機能の一部を実装します。デフォルトでは、これらの eBPF プログラムは、Ingress Node Firewall に固有のメカニズムを使用してカーネルにロードされます。
クラスター管理者は、Ingress Node Firewall Operator を設定して、代わりに eBPF Manager Operator を使用してこれらのプログラムをロードおよび管理し、セキュリティーと監視機能を追加できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - 管理者権限を持つアカウントがある。
- Ingress Node Firewall Operator をインストールしました。
- eBPF Manager Operator をインストールしている。
手順
ingress-node-firewall-systemnamespace に次のラベルを適用します。$ oc label namespace openshift-ingress-node-firewall \ pod-security.kubernetes.io/enforce=privileged \ pod-security.kubernetes.io/warn=privileged --overwriteingressnodefirewallconfigという名前のIngressNodeFirewallConfigオブジェクトを編集し、ebpfProgramManagerModeフィールドを設定します。Ingress Node Firewall Operator 設定オブジェクト
apiVersion: ingressnodefirewall.openshift.io/v1alpha1 kind: IngressNodeFirewallConfig metadata: name: ingressnodefirewallconfig namespace: openshift-ingress-node-firewall spec: nodeSelector: node-role.kubernetes.io/worker: "" ebpfProgramManagerMode: <ebpf_mode>ここでは、以下のようになります。
<ebpf_mode>: Ingress Node Firewall Operator が eBPF Manager Operator を使用して eBPF プログラムを管理するかどうかを指定します。trueまたはfalseのどちらかでなければなりません。設定されていないと、eBPF マネージャーは使用されません。
4.6. Ingress Node Firewall Operator ルールの表示 リンクのコピーリンクがクリップボードにコピーされました!
手順
次のコマンドを実行して、現在のルールをすべて表示します。
$ oc get ingressnodefirewall返された
<resource>名のいずれかを選択し、次のコマンドを実行してルールまたは設定を表示します。$ oc get <resource> <name> -o yaml
4.7. Ingress Node Firewall Operator のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
次のコマンドを実行して、インストールされている Ingress ノードファイアウォールのカスタムリソース定義 (CRD) を一覧表示します。
$ oc get crds | grep ingressnodefirewall出力例
NAME READY UP-TO-DATE AVAILABLE AGE ingressnodefirewallconfigs.ingressnodefirewall.openshift.io 2022-08-25T10:03:01Z ingressnodefirewallnodestates.ingressnodefirewall.openshift.io 2022-08-25T10:03:00Z ingressnodefirewalls.ingressnodefirewall.openshift.io 2022-08-25T10:03:00Z次のコマンドを実行して、Ingress Node Firewall Operator の状態を表示します。
$ oc get pods -n openshift-ingress-node-firewall出力例
NAME READY STATUS RESTARTS AGE ingress-node-firewall-controller-manager 2/2 Running 0 5d21h ingress-node-firewall-daemon-pqx56 3/3 Running 0 5d21h次のフィールドは、Operator のステータスに関する情報を提供します:
READY、STATUS、AGE、およびRESTARTS。Ingress Node Firewall Operator が割り当てられたノードに設定されたデーモンをデプロイしている場合、STATUSフィールドはRunningになります。次のコマンドを実行して、すべての Ingress ファイアウォールノード Pod のログを収集します。
$ oc adm must-gather – gather_ingress_node_firewallログは、
/sos_commands/ebpfにある eBPFbpftool出力を含む sos ノードのレポートで利用できます。これらのレポートには、Ingress ファイアウォール XDP がパケット処理を処理し、統計を更新し、イベントを発行するときに使用または更新されたルックアップテーブルが含まれます。
Legal Notice
リンクのコピーリンクがクリップボードにコピーされました!
Copyright © Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of the OpenJS Foundation.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.