egress を制限しながらアプリを動作させる

はじめに

Meadow Supply は、API を通じて実際の在庫状況を表示し、練習用の買い物かごの見積もりを計算する必要があります。この独立した環境では、元のアプリケーションは動いていますが、古い API の egress 移行ルールが広範な TCP 接続を許可する一方、DNS を含め忘れています。そのため、カタログには在庫状況のエラーが表示されます。必要な依存先への接続を修復してから、ショップや別の集荷サービスを壊さずに、古いルールの不要な権限を取り除きます。

前のガイド付き実験で学んだ、名前空間、ロール、ポリシー、ターミナル、実際のリクエストの方法を使ってください。この実験では、egress、DNS のプロトコルとポートの要件、ターミナルの変数、ポリシーの和集合を、使う前に説明します。準備済みの実際の単一ノードクラスターには、完全なアプリケーションと承認済みの在庫 ingress が独立して含まれています。前の VM のファイルやプロセスは不要です。クラスターのインストールやアプリケーションのプログラミングは必要ありません。所要時間は作者の見積もりであり、初学者の実測時間ではありません。商品と集荷メモはすべて合成データで、練習用の見積もりによって予約、注文、課金が行われることはありません。

API に必要な依存接続を復旧する

このステップでは、すべての宛先を開放せずに、Shop API の実際の DNS 接続と在庫接続を復旧します。

Shop を開きます。期待する完全な結果は、前と同じ 3 商品の Meadow Supply カタログです。Glass water bottle は $18.00 で 6 個、Everyday notebook は $14.00 で 4 個、Canvas market bag は $24.00 で 0 個です。初期状態では、代わりに Live availability unavailable. と表示されます。価格は見えますが、アプリケーションには在庫のフォールバックがなく、有効な見積もりを生成できません。これは、修復対象として意図した依存接続の障害です。在庫が空であると取り違えてはいけません。Reference には、元の 2 件の集荷メモが引き続き表示されるはずです。Workspace に切り替えます。

この独立したワークスペースは /home/labex/project/stock-policy です。必要なら、前と同じ pwd、ls、絶対パスの cd によるパスの復旧を使います。配布された作業範囲を読みます。

cd /home/labex/project/stock-policy

cat scope.json

この VM には、在庫への ingress 境界がすでに準備されています。meadow-shop の API ロールを許可しています。そのポリシーは変更しないでください。API の送信接続は、別途制御されます。Egress は、選択された Pod から出ていく通信を意味します。Pod を選択する Egress ポリシーは、その方向について Pod を分離し、適用対象となるすべての egress ルールの和集合によって、外へ出てよい通信が決まります。許可された接続への応答通信は、暗黙に許可されます。

API の名前空間にある既存の移行ポリシーを読みます。

kubectl --context=labex-v135 -n meadow-shop get networkpolicies

kubectl --context=labex-v135 -n meadow-shop describe networkpolicy legacy-egress

legacy-egress は role=shop-api を選択し、TCP ポート 8080 を任意の宛先へ許可します。DNS は含まれていません。CoreDNS は準備済みのクラスターの名前サービスです。Service 名を使う場合、HTTP 接続でそのアドレスを使う前に DNS クエリが必要です。DNS（Domain Name System）は、名前をアドレスに変換します。UDP（User Datagram Protocol）は個々のデータグラムを送り、TCP（Transmission Control Protocol）は接続を確立します。このクラスターの DNS サービスは、ポート 53 で両方を受け入れるため、kube-system の DNS Pod に対する両方の経路が必要です。

配布された診断ツールの dns モードは、その Pod のリゾルバーに新しい UDP DNS クエリを送ります。dns-tcp は新しい TCP クエリを送ります。どちらも、アプリケーションがキャッシュした結果には依存しません。実際の API の実行主体をテストします。

./tools/network-test api dns stock.meadow-stock.svc.cluster.local

./tools/network-test api dns-tcp stock.meadow-stock.svc.cluster.local

どちらも NETWORK_TIMEOUT とゼロ以外の終了コードを報告するはずです。これらの想定された失敗は、DNS 接続に関するものです。在庫プロセスの停止と区別するため、元の在庫 Service のアドレスへ、明示的な診断リクエストを 1 回送ります。

次の代入は、$(...) でコマンドの出力を取得し、シェル変数 stock_ip に入れます。-o jsonpath='{.spec.clusterIP}' は、Service の spec.clusterIP フィールドだけを選びます。引用符は式をひとまとまりに保ちます。この変数は、現在の Workspace ターミナルセッションに属します。診断用の値であり、ポリシーの対象や永続的な Pod アドレスではありません。新しいシェルに再接続した場合は、使う前に代入を繰り返してください。

stock_ip=$(kubectl --context=labex-v135 -n meadow-stock get service stock -o jsonpath='{.spec.clusterIP}')

printf は取得した文字列を表示します。%s は文字列を意味し、\n は行を終えます。二重引用符は、展開後の値を 1 つの引数として維持します。

printf '%s\n' "$stock_ip"

${stock_ip} は、リクエスト URL 内でその変数を展開します。既存の広範な TCP ルールによって、DNS を使わずにこの接続が許可されます。

./tools/network-test api http "http://${stock_ip}:8080/stock.json"

HTTP_REPLY 200 と元の在庫レコードが期待されます。TCP アクセスは可能ですが、名前の解決は別の依存接続です。そのアドレスを完成したポリシーに入れてはいけません。安定した名前空間とロールの関係を使ってください。

選択する前に、実際の DNS ラベルを調べます。-l k8s-app=kube-dns は、準備済みの DNS Pod を選びます。

kubectl --context=labex-v135 get namespace kube-system --show-labels

kubectl --context=labex-v135 -n kube-system get pods -l k8s-app=kube-dns --show-labels

自分の api-egress ポリシーを作成します。API ロールを選択します。2 つの to ルールは選択肢であり、UDP/TCP 53 の kube-system 内の DNS、または TCP 8080 の meadow-stock 内の在庫を許可します。個々の相手先の内部では、名前空間と Pod のセレクターが AND で結合されます。各ルールのポートは、そのルールの宛先だけに適用されます。

mkdir -p は、既存のリリースディレクトリを維持します。前に学んだように、引用符付きのヒアドキュメントと > は、自分の編集可能なリリースファイルだけに書き込みます。

mkdir -p release

cat > release/api-egress.yaml <<'YAML'
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-egress
  namespace: meadow-shop
spec:
  podSelector:
    matchLabels:
      role: shop-api
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: meadow-stock
          podSelector:
            matchLabels:
              role: inventory
      ports:
        - protocol: TCP
          port: 8080
YAML

保存したマニフェストを読み、適用して調べます。

cat release/api-egress.yaml

kubectl --context=labex-v135 apply -f release/api-egress.yaml

kubectl --context=labex-v135 -n meadow-shop describe networkpolicy api-egress

実際の両方の DNS トランスポートと、名前による在庫接続を確認します。適用後、制御が行き渡るまで数秒かかることがあります。以前の通信境界の動作がまだ見える場合は、少し待ってからリクエストを繰り返してください。

./tools/network-test api dns stock.meadow-stock.svc.cluster.local

./tools/network-test api dns-tcp stock.meadow-stock.svc.cluster.local

./tools/network-test api http http://stock.meadow-stock.svc.cluster.local:8080/stock.json

DNS_REPLY UDP、DNS_REPLY TCP、続いて HTTP_REPLY 200 と元の在庫データ全体が期待されます。Shop に切り替えて再読み込みします。実際の在庫状況が戻るはずです。Glass water bottle を開き、Quantity 2 を選び、Try a basket quote を使います。Ready for collection、合計 $36.00、提供可能数 6 個と、予約しない旨の練習用注意書きが期待されます。Back to product と Back to collection で戻ります。

復旧した実際のカタログを、この実際の稼働結果と比較してください。

必要な依存接続を復旧した Meadow Supply

これで必要な接続の修復は完了ですが、無関係な宛先を拒否できた証拠にはまだなりません。他のポリシーが権限を追加している場合があります。これを最終的な通信境界と見なす前に、次のステップへ進んでください。

打ち間違いの場合は、pwd、ls、絶対パスの cd で戻ります。マニフェストが不正な場合や依存接続のリクエストが失敗する場合は、保存したファイル、describe の出力、学んだ実際のラベルとポートを読み、ファイルを修正して再適用してください。DNS_REPLY は名前サービスの結果、HTTP_REPLY はアプリケーションの応答、NETWORK_TIMEOUT は準備されたネットワークのタイムアウト時間内に応答がないこと、CONNECTION_REFUSED は宛先が接続を拒否したことを示します。ツールの制限時間付き REQUEST_TIMEOUT は、DNS を含むリクエスト全体が対象です。単に失敗しただけでは、正しいポリシーを確認できません。アプリケーションコード、ラベル、ソースファイル、元の Pod、在庫 ingress、Service、ホストのネットワーク設定、DNS 基盤を変更してはいけません。

古い広範な権限を廃止する

このステップでは、修復した顧客操作と別の集荷サービスを維持しながら、古い移行ポリシーの不要な許可を取り除きます。

Workspace の /home/labex/project/stock-policy から始めます。新しいポリシーは、DNS と在庫だけを許可します。API から、無関係な集荷サービスをテストします。

./tools/network-test api http http://dispatch.meadow-stock.svc.cluster.local:8080/notes.json

現在は、HTTP_REPLY 200 と 2 件の集荷メモを返します。この成功は権限の漏れを示しています。Shop API には、集荷情報へのアクセスは不要です。新しい狭いポリシーは、既存の広いポリシーを上書きしません。NetworkPolicy は、適用順に関係なく許可された接続を足し合わせます。接続が機能するには、送信元の egress と宛先の ingress の両方が許可しなければなりません。

両方のポリシーをもう一度一覧表示してから、管理対象の移行ポリシーとその元のソースを読みます。

kubectl --context=labex-v135 -n meadow-shop get networkpolicies

kubectl --context=labex-v135 -n meadow-shop describe networkpolicy legacy-egress

cat starter/legacy-egress.yaml

古いルールは、to の宛先制限なしで TCP ポート 8080 を許可します。その権限は、選択された API Pod に引き続き適用されます。このリリースでは、元の管理対象 legacy-egress オブジェクトを保持し、その場で権限を廃止します。空のリスト egress: [] で表す、egress の許可項目がない状態として保存します。別の api-egress ポリシーは、必要な 2 種類の接続を引き続き提供します。読み取り専用のスターターは変更しないでください。

cat > release/legacy-egress.yaml <<'YAML'
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: legacy-egress
  namespace: meadow-shop
spec:
  podSelector:
    matchLabels:
      role: shop-api
  policyTypes:
    - Egress
  egress: []
YAML

保存した管理対象ポリシーを読み、適用します。削除して再作成してはいけません。

cat release/legacy-egress.yaml

kubectl --context=labex-v135 apply -f release/legacy-egress.yaml

kubectl --context=labex-v135 -n meadow-shop describe networkpolicy legacy-egress

引き続き API ロールを選択しますが、送信の許可は一切追加しないはずです。最終的なリリースディレクトリには、保存した両方のポリシーが含まれます。準備済みの在庫 ingress ポリシーは変更しません。

今度は、API の無関係な集荷リクエストはタイムアウトし、そのまったく同じサービスへの顧客による対照リクエストは、引き続き成功する必要があります。

./tools/network-test api http http://dispatch.meadow-stock.svc.cluster.local:8080/notes.json

./tools/network-test customer http http://dispatch.meadow-stock.svc.cluster.local:8080/notes.json

API では NETWORK_TIMEOUT とゼロ以外の終了コード、続いて Customer では HTTP_REPLY 200 と変更されていない両方のメモが期待されます。この組み合わせにより、サービス停止を正しい分離と取り違えることを防ぎます。適用直後に API のリクエストがまだ成功する場合は、数秒待ち、実際の新しい通信境界が観測できるまで繰り返してください。

承認された在庫経路と、両方の DNS プロトコルをもう一度確認します。

./tools/network-test api http http://stock.meadow-stock.svc.cluster.local:8080/stock.json

./tools/network-test api dns stock.meadow-stock.svc.cluster.local

./tools/network-test api dns-tcp stock.meadow-stock.svc.cluster.local

Shop に切り替えて再読み込みし、Glass water bottle の Quantity 2 の見積もりを繰り返します。Ready for collection、**$36.00、6 個です。その後、Canvas market bag、Quantity 1** を見積もります。Not enough stock、**$24.00、0 個です。コレクションに戻り、Our approach** を開いて練習の範囲を確認します。Reference に切り替えて再読み込みします。元の両方の集荷メモが残っています。Download notes を使い、実際の 2 レコードのダウンロードを調べます。このブラウザーダウンロードはターミナルのワークスペースとは別で、そこにコピーする必要はありません。

引き渡すのは release/api-egress.yaml と release/legacy-egress.yaml であり、元のポリシーの識別情報を維持して適用します。実際の権限と保存した権限の両方が、学んだ名前空間とロール、プロトコルとポートの境界に一致する必要があります。DNS は UDP/TCP 53、在庫は TCP 8080 で、古いポリシーは許可を一切追加しません。元のアプリケーションリソース、Pod、名前空間ラベル、データ、配布されたソースをすべて保持してください。修正によってショップが壊れた場合は、学んだ DNS と在庫の経路を調べ、編集可能なポリシーファイルだけを直して再適用します。別の全許可ルールを追加したり、DNS を迂回するためにアプリケーションを変えたりしてはいけません。これら有限回の TCP/UDP 観測は、本番環境でノードや管理者から保護するネットワークセキュリティ境界の証明ではありません。

まとめ

名前解決とアプリケーションへの接続を切り分け、API の実際の DNS と在庫への依存接続を復旧して、実際の顧客向け見積もりを動作させ続けました。また、狭いポリシーで別のポリシーの権限を取り除けなかった理由を見つけ、その無関係なサービスを停止せずに、古い権限を廃止しました。

最終的に保存したリリースと実際のポリシーの和集合は、必要な DNS と在庫の経路を許可しながら、API から集荷サービスへのアクセスを拒否します。ポリシーの順番が優先順位になるわけではありません。失敗を解釈するときは、組み合わせた権限を評価し、正常に動作する対照の接続も維持してください。