Kube-Mgmt を使用して OPA を Kubernetes クラスターに統合する

OPA と呼ばれる Open Policy Agent は、オープンソースの汎用ポリシーエージェントエンジンであり、CNCF の卒業プロジェクトです。 OPA は、ポリシールールの定義を簡素化し、プログラム内のポリシーの意思決定の負担を軽減する高レベルの宣言型言語である Rego を提供します。 OPA は、マイクロサービス、Kubernetes、CI/CD、API ゲートウェイなどのシナリオでポリシーを定義するために使用できます。

ここでは主に、Kubernetes に OPA を統合する方法について説明します。 Kubernetes では、OPA は Admission Controller を通じてセキュリティポリシーを実装します。セキュリティポリシーを適用するために (非推奨の) Pod セキュリティポリシーを使用することは問題ありませんが、定義上、PSP は Pod にのみ適用できます。 Ingress、デプロイメント、サービスなどの他の Kubernetes リソースを処理することはできません。OPA の強みは、あらゆる Kubernetes リソースに適用できることです。 OPA は、APIServer に送信された API 呼び出しをインターセプトし、検証および/または変更するアドミッションコントローラーとして Kubernetes にデプロイされます。ポッドだけでなく、システムのさまざまなコンポーネントに適用される統合 OPA ポリシーを設定できます。たとえば、ユーザーにサービスで会社のドメインを使用するように強制し、ユーザーが会社のレジストリからのみイメージをプルするようにするポリシーなどです。

概要

OPA はポリシーの決定とポリシーの実行を分離します。アプリケーションがポリシー決定を行う必要がある場合、OPA にクエリを実行し、構造化データ (JSON など) を入力として提供します。 OPA は任意の構造化データを入力として受け入れます。

OPA は、クエリ入力ポリシーとデータを評価してポリシー決定を生成します。次のような、ポリシー内のほぼすべての不変要素を記述できます。

どのユーザーがどのリソースにアクセスできるか。
どのサブネットの出力トラフィックが許可されるか。
ワークロードをどのクラスターにデプロイする必要があるか。
バイナリはどこからダウンロードできますか?
コンテナはどのようなオペレーティングシステム機能を使用して実行できますか?
システムにアクセスできる時間帯。

ポリシーの決定は単純な「はい/いいえ」や「許可/拒否」に限定されません。クエリ入力だけでなく、ポリシーでは出力として任意の構造化データを生成できます。例を見てみましょう。 OPA ポリシーは、複雑な階層型データ構造のポリシーを表現するために特別に設計された、Rego と呼ばれる高レベルの宣言型言語を使用して宣言されます。

Kubernetes では、アドミッションコントローラーは、作成、更新、削除の操作中にオブジェクトに対してポリシーを適用します。アドミッションコントロールは、Kubernetes におけるポリシー適用の基礎となります。 OPA をアドミッションコントローラーとして導入すると、次のことが可能になります。

すべてのリソースに特定のタグが必要です。
コンテナイメージはエンタープライズイメージリポジトリから取得する必要があります。
すべてのポッドにリソース要求と制限を指定するよう要求します。
競合する Ingress オブジェクトの作成を防ぎます。
......

Kubernetes API サーバーは、オブジェクトの作成、更新、または削除時に、OPA にアドミッションコントロールポリシーを照会するように構成されています。 APIServer は、Webhook リクエスト内のオブジェクト全体を OPA に送信します。OPA は、アドミッションレビューを入力として使用して、ロードしたポリシーを評価します。これは、コードを記述する必要がないことを除けば、実際にはアドミッションコントローラーを自分で実装するのと似ています。ポリシールールを記述するだけで、OPA はルールに従って入力オブジェクトを検証できます。

展開する

次に、Kubernetes クラスターに OPA を統合する方法を紹介します。 OPA はアドミッションコントローラーを介して Kubernetes に統合されているため、クラスターで ValidatingAdmissionWebhook アドミッションコントローラーを有効にする必要があります。

まず、opa という名前空間を作成します。これにより、OPA は名前空間内の ConfigMap からポリシーをロードできるようになります。

 ➜ kubectl 名前空間opa を作成します

コンテキストを opa 名前空間に変更します。

 ➜ kubectl config 現在のコンテキスト
kubernetes - 管理者@ kubernetes
 ➜ コンテンツkubectl config set - context kubernetes - admin @ kubernetes --namespace = opa 
 コンテキスト「kubernetes-admin@kubernetes」 が変更されました。
 ➜ kubectl ポッドを取得する
opa 名前空間にリソースが見つかりません。

APIServer と OPA 間の通信を保護するには、TLS 証明書を構成する必要があります。

証明機関とキーを作成します。

 ➜ openssl genrsa -out ca 。 キー2048
 ➜ openssl req - x509 - new - nodes - key ca 。 キー日数100000 アウトca .  crt - 件名"/CN=admission_ca"

OPA のキーと証明書を生成します。

 cat > サーバー。 conf << EOF
 [ 必須]
 要求拡張機能= v3_req
 識別名= 必須識別名
[ 必須識別名]
 [ v3_req ]
 基本制約= CA : FALSE
 keyUsage = 非否認、 デジタル署名、 キー暗号化
拡張キー使用法= クライアント認証、 サーバー認証
subjectAltName = @alt_names
 [ 別名]
 DNS .1 = opa . オパ。 サービス
終了
➜ openssl genrsa - out サーバー。 キー2048
 ➜ openssl req- 新しいキーサーバー。  キーアウトサーバー。 csr - subj "/CN=opa.opa.svc" - 構成サーバー。 会議
➜ openssl x509 - req - in サーバー。 csr - CA ca . crt - CAkey ca 。 キー- CAcreateserial - out サーバー。 crt - 日数100000 - 拡張子v3_req - extfile サーバー。 会議

OPA 資格情報を保存するための Kubernetes TLS シークレットを作成します。

 ➜ kubectl create secret tls opa - server --cert = server 。 crt -- キー= サーバー。 鍵

証明書の準備ができたら、アドミッションコントローラーをデプロイできます。対応するリソースマニフェストファイルは次のとおりです。

 # opa - アドミッション- コントローラ.yaml
 # OPA / kube - mgmtにリソースへの読み取り専用アクセス権を付与します。 これにより、 kube - mgmt
 # リソースをOPA に複製して、 ポリシーで使用できるようにします。
 種類: ClusterRoleBinding
 apiバージョン: rbac 。 承認。 k8s 。 io / v1
 メタデータ:
 名前: opa - 視聴者
ロールリファレンス:
 種類: ClusterRole
 名前: ビュー
apiグループ: rbac 。 承認。 k8s 。 io
 科目:
 - 種類: グループ
名前: システム: サービスアカウント: opa
 apiグループ: rbac 。 承認。 k8s 。 io
 -- -
 # ポリシーステータスでconfigmaps を更新するためのOPA / kube - mgmt のロールを定義します。
 種類: 役割
apiバージョン: rbac 。 承認。 k8s 。 io / v1
 メタデータ:
 名前空間: opa
 名前: configmap - 修飾子
ルール:
 -apiグループ: [ "" ]
 リソース: [ "configmaps" ]
 動詞: [ 「更新」 、 「パッチ」 ]
 -- -
 # 上記で定義したOPA / kube - mgmt ロールを付与します。
 種類: RoleBinding
 apiバージョン: rbac 。 承認。 k8s 。 io / v1
 メタデータ:
 名前空間: opa
 名前: opa - configmap - 修飾子
ロールリファレンス:
 種類: 役割
名前: configmap - 修飾子
apiグループ: rbac 。 承認。 k8s 。 io
 科目:
 - 種類: グループ
名前: システム: サービスアカウント: opa
 apiグループ: rbac 。 承認。 k8s 。 io
 -- -
 種類: サービス
APIバージョン: v1
 メタデータ:
 名前: オパ
名前空間: opa
 仕様:
 セレクター:
 アプリ: opa
 ポート:
 - 名前: https
 ポート: 443
 ターゲットポート: 443
 -- -
 種類: ClusterRoleBinding
 apiバージョン: rbac 。 承認。 k8s 。 io / v1
 メタデータ:
 名前: opa - 閲覧者
ロールリファレンス:
 種類: ClusterRole
 名前: ビュー
apiグループ: rbac 。 承認。 k8s 。 io
 科目:
 - 種類: グループ
名前: システム: サービスアカウント: opa
 apiグループ: rbac 。 承認。 k8s 。 io
 -- -
 # ポリシーステータスでconfigmaps を更新するためのOPA / kube - mgmt のロールを定義します。
 種類: 役割
apiバージョン: rbac 。 承認。 k8s 。 io / v1
 メタデータ:
 名前空間: opa
 名前: configmap - 修飾子
ルール:
 -apiグループ: [ "" ]
 リソース: [ "configmaps" ]
 動詞: [ 「更新」 、 「パッチ」 ]
 -- -
 # 上記で定義したOPA / kube - mgmt ロールを付与します。
 種類: RoleBinding
 apiバージョン: rbac 。 承認。 k8s 。 io / v1
 メタデータ:
 名前空間: opa
 名前: opa - configmap - 修飾子
ロールリファレンス:
 種類: 役割
名前: configmap - 修飾子
apiグループ: rbac 。 承認。 k8s 。 io
 科目:
 - 種類: グループ
名前: システム: サービスアカウント: opa
 apiグループ: rbac 。 承認。 k8s 。 io
 -- -
 種類: サービス
APIバージョン: v1
 メタデータ:
 名前: オパ
名前空間: opa
 仕様:
 セレクター:
 アプリ: opa
 ポート:
 - 名前: https
 プロトコル: TCP
 ポート: 443
 ターゲットポート: 443
 -- -
 apiバージョン: アプリ/ v1
 種類: デプロイメント
メタデータ:
 名前: オパ
名前空間: opa
 仕様:
 セレクター:
 マッチラベル:
 アプリ: opa
 テンプレート：
 メタデータ:
 ラベル:
 アプリ: opa
 仕様:
 コンテナ:
 - 名前: オパ
画像: openpolicyagent / opa : 最新
引数:
 - "走る"
 - "--サーバー"
 - "--tls-cert-file=/certs/tls.crt"
 - "--tls-private-key-file=/certs/tls.key"
 - "--addr=0.0.0.0:443"
 - "--addr=http://127.0.0.1:8181"
 - "--log-level=デバッグ"
 - "--log-format=json-pretty"
 ボリュームマウント:
 - 読み取り専用: true
 マウントパス: /certs
 名前: opa - サーバー
準備状況プローブ:
 httpGet : 取得:
 パス: /health
 スキーム: HTTPS
 ポート: 443
 初期遅延秒数: 5
 期間秒数: 10
 ライブネスプローブ:
 httpGet : 取得:
 パス: /health
 スキーム: HTTPS
 ポート: 443
 初期遅延秒数: 10
 期間秒数: 15
 - 名前: kube - mgmt
 イメージ: openpolicyagent / kube - 管理: 4.0.0
 引数:
 - --replicate - クラスター= v1 / 名前空間
-- 複製= ネットワーキング。 k8s 。 io / v1 / イングレス
- -- opa - URL = http://127.0.0.1:8181/v1
 --enable - データ= true
 --enable - ポリシー= true
 - --policies = opa
 - -- 必須- ポリシー- ラベル= true
 巻数:
 - 名前: opa - サーバー
秘密：
 secretName : opa - サーバー
-- -
 種類: ConfigMap
 APIバージョン: v1
 メタデータ:
 名前: opa - デフォルト- システム- メイン
名前空間: opa
 ラベル:
 openpolicyagent .org / ポリシー: rego
 データ：
 メイン: |
 パッケージシステム
データをインポートします。 Kubernetes 。 入場料
メイン= {
 「apiバージョン」 : 「admission.k8s.io/v1」 、
 "種類" : "入学レビュー" ,
 「応答」 : 応答、
 }
 デフォルトのuid = ""
 uid = 入力。 リクエスト。 ユーザID
 レスポンス= {
 「許可」 : false 、
 「uid」 : uid 、
 "状態" ： {
 「メッセージ」 : 理由、
 },
 } {
 理由= concat ( ", " , 入場. 拒否)
 理由!= ""
 }
 そうでない場合= { "allowed" : true 、 "uid" : uid }

上記のリソースリストでは、ConfigMap オブジェクト内のポリシーを OPA に動的にロードできる kube-mgmt Sidecar コンテナーを追加しました。 kube-mgmt コンテナは、他の Kubernetes オブジェクトを JSON データとして OPA にロードすることもできます。

もう 1 つ注意すべき点は、サービスの名前 (opa) が証明書に設定されている CN と一致する必要があることです。一致しないと、TLS 通信が失敗します。 kube-mgmt コンテナでは、次のコマンドラインパラメータも指定されます。

--replicate-cluster=v1/namespaces です。
--replicate=networking.k8s.io/v1/ingresses です。
--enable-policies=true を指定します。
--policies=opa です。
--require-policy-label=true を指定します。

最初の 2 つのパラメータにより、サイドカーコンテナは名前空間と Ingress オブジェクトをコピーし、OPA エンジンに読み込むことができます。 enable-policies=true は、OPA ポリシーが Configmap を通じてロードされることを意味します。次の --policies=opa は、opa 名前空間の Configmap からポリシーをロードすることを意味します。 --require-policy-label=true パラメータも構成されている場合、Configmap には、自動的にロードされるラベル openpolicyagent.org/policy=rego が必要です。

上記のリソースリストを適用するだけです。

 ➜ kubectl apply -f opa -admission - controller .yaml  
 ➜ kubectl ポッドを取得する
名前準備完了ステータス再起動年齢
opa - 6 cd68f74f - s9zcv 2 / 2 実行中0 5 m28s

アドミッションコントローラーが機能するためには、アドミッション HTTP コールバックを受信して実行するためのアドミッション Webhook も必要です。以下に示すように、Webhook 構成ファイルを作成します。

 ➜ cat > webhook - 構成.yaml << EOF
 種類: ValidatingWebhookConfiguration
 apiバージョン: admissionregistration 。 k8s 。 io / v1
 メタデータ:
 名前: opa - 検証- webhook
 ウェブフック:
 - 名前: 検証中の- Webhook 。 オープンポリシーエージェント。 組織
入場レビューバージョン: [ "v1" 、 "v1beta1" ]
 名前空間セレクタ:
 一致する表現:
 - キー: openpolicyagent .org / webhook
 演算子: NotIn
 値：
 - 無視する
失敗ポリシー: 無視
ルール:
 -apiグループ:
 - '*'
 apiバージョン:
 - '*'
 操作:
 - '*'
 リソース：
 - '*'
 副作用: なし
クライアント構成:
 caBundle : $ ( cat ca . crt | base64 | tr - d '\n' )
 サービス：
 名前空間: opa
 名前: オパ
終了

上記の Webhook では次のプロパティが構成されています。

openpolicyagent.org/webhook=ignore のタグが付けられた名前空間からのアクションはリッスンされません。
すべてのリソース操作を監視します。
OPA と通信できるように、先ほど作成した CA 証明書を使用します。

ここで、構成を使用する前に、kube-system および opa 名前空間が webhook スコープ内に含まれないようにマークします。

 ➜ kubectl label ns kube - system openpolicyagent 。 org / webhook = 無視
➜ kubectl label ns opa openpolicyagent 。 org / webhook = 無視

次に、上記の構成オブジェクトを適用して、OPA をアドミッションコントローラーとして登録します。

 ➜ kubectl apply -f webhook - 構成.yaml 
 ➜ kubectl ポッドを取得する
名前準備完了ステータス再起動年齢
opa - 6 cd68f74f - s9zcv 2 / 2 ランニング0 72 m
 ➜ kubectl で検証Webhook設定を取得
名前ウェブフック年齢
opa - 検証- webhook 1 2 分 14 秒

ポリシーの例

OPA はポリシーを記述するために Rego 言語を使用します。ここでは、公式ドキュメントに記載されている例を使用して、Ingress で使用できるホスト名を制限し、指定された正規表現に一致するホスト名のみを許可するホスト名ポリシーを説明および作成します。

次のような ingress-allowlist.rego という名前のポリシーファイルを作成します。

 パッケージkubernetes .admission
 操作= { "CREATE" 、 "UPDATE" }
 拒否[ メッセージ] {
 入力します。 リクエスト。 親切。 種類== "Ingress"
 操作[ 入力. リクエスト。 手術]
 ホスト: = 入力。 リクエスト。 物体。 スペック。 ルール[ _ ]。 ホスト
fqdn_matches_any ( ホスト、 valid_ingress_hosts ) ではない
msg : = sprintf ( "無効な入力ホスト %q" 、[ ホスト])
 }
 valid_ingress_hosts = { ホスト|
 allowlist : = 名前空間[ 入力. リクエスト。 名前空間]。 メタデータ。 注釈[ "ingress-allowlist" ]
 ホスト: = split ( allowlist , ", " )
 ホスト: = ホスト[ _ ]
 }
 fqdn_matches_any ( 文字列, パターン) {
 fqdn_matches ( 文字列, パターン[ _ ])
 }
 fqdn_matches ( 文字列, パターン) {
 pattern_parts : = split ( パターン, "." )
 パターンパーツ[ 0 ] == "*"
 str_parts : = split ( str , "." )
 n_pattern_parts : = count ( パターンパーツ)
 n_str_parts : = count ( str_parts )
 n_pattern_parts == n_str_parts
 suffix : = trim ( パターン, "*." )
 endswith ( 文字列, 接尾辞)
 }
 fqdn_matches ( 文字列, パターン) {
 含まれない( パターン, "*" )
 str == パターン
}

Rego を初めて使用する場合は、上記のコードが少し奇妙に見えるかもしれませんが、Rego を使用するとポリシーの定義が非常に簡単になります。ホワイトリストの Ingress 名前空間を使用してこのポリシーがどのように適用されるかを分析してみましょう。

1 行目:パッケージは他の言語と同じように使用されます。

5 行目: CREATE と UPDATE の 2 つの操作でデータセットを定義します。

7 行目:これはポリシーの中核部分であり、deny で始まり、その後にポリシー本体が続きます。本文のステートメントの組み合わせが true と評価された場合、ポリシー違反となり、アクションはブロックされ、アクションがブロックされた理由を説明するメッセージがユーザーに返されます。

8 行目:入力オブジェクトを指定します。OPA に送信されるすべての JSON メッセージは入力オブジェクトのルートから開始され、問題のリソースが見つかるまで JSON オブジェクトを反復処理します。ポリシーを適用するには、そのリソースが Ingress である必要があります。

9 行目:リソースを作成または更新するには、ポリシーを適用する必要があります。 Rego では、operations[input.requset.operations] を使用してこれを実行できます。角括弧内のコードは、リクエストで指定された操作を抽出します。 5 行目の操作セットで定義された要素と一致する場合、ステートメントは true になります。

10 行目: Ingress オブジェクトのホスト情報を抽出するには、JSON オブジェクトのルール配列を反復処理する必要があります。ここでも、Rego は配列をループし、すべての要素をホスト変数に返す _ 文字を提供します。

11 行目:ホスト変数を取得したので、それがホワイトリストに登録されたホストではないことを確認する必要があります。ポリシーが true と評価された場合にのみポリシー違反となることに注意してください。ホストが有効かどうかを確認するには、21 行目に定義されている fqdn_matches_any 関数を使用します。

行 12: Ingress オブジェクトを作成できなかった理由を説明する、ユーザーに返されるメッセージを定義します。

15 行目から 19 行目:この部分では、Ingress 名前空間の注釈からホワイトリストに登録されたホスト名を抽出します。ホスト名はコンマ区切りのリストで追加されます。リストに変換するには、組み込み関数の split を使用します。最後に、_ を使用して抽出されたホストリスト全体を反復処理し、結果を | 経由でホスト変数にパイプします。 (これは Python のリスト内包表記と非常によく似ています)。

21 行目:この関数は文字列のみを受け取り、2 番目の引数であるパターンのリスト内でそれを検索します。これは実際には、以下の fqdn_matches 関数を呼び出すことによって実現されます。 Rego では、すべて同じ出力を生成する限り、同じ名前で複数の関数を定義できます。また、複数回定義された関数が呼び出されると、その関数のすべてのインスタンスが呼び出されます。

25 行目〜 33 行目:最初の fqdn_matches 関数の定義。

まず、パターンをドット . で分割します。たとえば、*.example.com は *、example、com に分割されます。
次に、パターンの最初のトークンがアスタリスクであることを確認し、入力文字列をで分割します。同じように。
消去 *。パターンで。
最後に、入力文字列がサフィックスで終わるかどうかが評価されます。たとえば、許可されたパターン文字列が *.mydomain.com であり、評価される文字列が www.example.com である場合、文字列は mydomain.com の一部ではないため、ポリシー違反になります。

35 行目から 38 行目: 2 番目の検証関数は、パターンが mycompany.mydomain.com と記述されている場合など、ワイルドカードなしでパターンを検証するために使用されます。

まず、提供されたパターンにワイルドカード文字が含まれていないことを確認する必要があります。そうでない場合、ステートメントは false と評価され、関数は続行されません。
パターンが特定のドメイン名を参照する場合は、FQDN がそのパターンと一致することを確認するだけです。つまり、パターンが mycompany.mydomain.com の場合、ホストの fqdn も mycompany.mydomain.com である必要があります。

同じ名前の関数が 2 つある理由は、関数が複数の出力結果を生成できないという Rego 言語の制限によるものです。したがって、異なるロジックで複数の検証を同時に実行する場合は、同じ名前の複数の関数を使用する必要があります。

実稼働環境では、Rego コードをクラスターに適用する前に、ユニットテストの追加や Rego Playground を使用してコードを検証するなど、包括的なテストを必ず実行してください。

このポリシーをクラスターに適用するには、上記の Rego ファイルを Configmap として opa 名前空間に適用する必要があります。

 ➜ kubectl create configmap ingress - allowlist --from - file = ingress - allowlist 。 登録
➜ kubectl ラベルconfigmap ingress - allowlist openpolicyagent .org / policy = rego

--require-policy-label パラメータを有効にしたので、対応するラベルも指定する必要があります。作成が完了したら、ポリシーが OPA によって取得され、構文エラーがないかどうかを確認することをお勧めします。 ConfigMap のステータスを確認できます:

 ➜ kubectl get cm ingress - allowlist - o json | jq '.metadata.annotations'
 {
 "openpolicyagent.org/policy-status" : "{\"ステータス\":\"OK\"}"
 }

次に、QA 環境用と本番環境用の 2 つの名前空間を作成します。どちらにも ingress-allowlist アノテーションが含まれており、これには Ingress ホスト名が一致する必要があるパターンが含まれていることに注意してください。

 # qa - 名前空間.yaml
 APIバージョン: v1
 種類: 名前空間
メタデータ:
 注釈:
 イングレス- 許可リスト: "*.qa.qikqiak.com、*.internal.qikqiak.com"
 名前: qa
 -- -
 # プロダクション- 名前空間.yaml
 APIバージョン: v1
 種類: 名前空間
メタデータ:
 注釈:
 イングレス- 許可リスト: "*.qikqiak.com"
 名前： プロダクション

上記の 2 つのリソースマニフェストファイルを適用するだけです。

 ➜ kubectl apply -f qa -namespace 。  yaml -f プロダクション- 名前空間。 ヤム

次に、ポリシーで許可される Ingress オブジェクトを作成しましょう。

 ➜ kubectl apply -f - << EOT 
 apiバージョン: ネットワーク。 k8s 。 io / v1
 種類: イングレス
メタデータ:
 名前: イングレス- OK
 名前空間: プロダクション
仕様:
 イングレスクラス名: nginx
 ルール:
 - ホスト: prod 。 キキキアック。 com
 http://www.google.com/dp ...
 パス:
 - バックエンド:
 サービス：
 名前: nginx
 ポート:
 番号： 80
 パス： /
 パスタイプ: プレフィックス
終了

通常、上記のリソースオブジェクトは次のように作成できます。

 ➜ kubectl の取得- n 本番環境
名前クラスホストアドレスポート年齢
イングレス- nginx prod は正常です。 キキキアック。 com 80 17 秒

次に、ポリシーに準拠しない Ingress オブジェクトを作成します。

 ➜ kubectl apply -f - << EOT 
 apiバージョン: ネットワーク。 k8s 。 io / v1
 種類: イングレス
メタデータ:
 名前: イングレス- 悪い
名前空間: qa
 仕様:
 イングレスクラス名: nginx
 ルール:
 - ホスト: opa . k8s 。 地元
http://www.google.com/dp ...
 パス:
 - バックエンド:
 サービス：
 名前: nginx
 ポート:
 番号： 80
 パス： /
 パスタイプ: プレフィックス
終了
サーバーからのエラー: 「test.yaml」 の作成中にエラーが発生しました: アドミッションWebhook 「validating-webhook.openpolicyagent.org」がリクエストを拒否しました: 無効なイングレスホスト「opa.k8s.local」

出力からわかるように、上記のオブジェクトは OPA ポリシールールに違反しているため、APIServer は Ingress オブジェクトの作成を拒否しました。

これで、Kubernetes コンポーネントを変更または再コンパイルすることなく、OPA を使用して Kubernetes クラスターにアドミッションコントロールポリシーを実装できました。さらに、OPA のバンドル機能戦略により、変化する運用要件に合わせてリモートサーバーから定期的にダウンロードすることができます。 OPA のより高度な機能については、以降の記事を参照してください。

<<: 「Eastern Data and Western Computing」がクラウド市場の爆発的な成長を加速します。事業者はチャンスを掴むために「3つの軸」に頼る必要がある

>>: Kubernetes リソース制限を調整する方法