2.13. セキュリティー
サービスメッシュアプリケーションが複雑な配列のマイクロサービスで構築されている場合、Red Hat OpenShift Service Mesh を使用してそれらのサービス間の通信のセキュリティーをカスタマイズできます。Service Mesh のトラフィック管理機能と共に OpenShift Container Platform のインフラストラクチャーを使用すると、アプリケーションの複雑性を管理し、マイクロサービスのセキュリティーを確保できるようにします。
作業を開始する前に
プロジェクトがある場合は、プロジェクトを ServiceMeshMemberRoll リソース に追加します。
プロジェクトがない場合は、Bookinfo サンプルアプリケーション をインストールし、これを ServiceMeshMemberRoll リソースに追加します。サンプルアプリケーションは、セキュリティーの概念を説明するのに役立ちます。
2.13.1. Mutual Transport Layer Security (mTLS) について リンクのコピーリンクがクリップボードにコピーされました!
Mutual Transport Layer Security (mTLS) は、二者が相互認証できるようにするプロトコルです。これは、一部のプロトコル (IKE、SSH) での認証のデフォルトモードであり、他のプロトコル (TLS) ではオプションになります。mTLS は、アプリケーションやサービスコードを変更せずに使用できます。TLS は、Service Mesh インフラストラクチャーおよび 2 つのサイドカープロキシー間で完全に処理されます。
デフォルトで、Red Hat OpenShift Service Mesh の mTLS は有効になっており、Permissive モードに設定されます。この場合、Service Mesh のサイドカーは、プレーンテキストのトラフィックと mTLS を使用して暗号化される接続の両方を受け入れます。厳密な mTLS を使用するように設定されたメッシュ内のサービスがメッシュ外のサービスと通信している場合、厳密な mTLS においてクライアントとサーバーの両方が互いの ID を検証できる必要があるため、これらのサービス間の通信が中断される可能性があります。ワークロードを Service Mesh に移行する間に Permissive モードを使用します。次に、メッシュ、namespace、またはアプリケーションで厳密な mTLS を有効にできます。
Service Mesh コントロールプレーンのレベルでメッシュ全体で mTLS を有効にすると、アプリケーションとワークロードを書き換えずに Service Mesh 内のすべてのトラフィックのセキュリティーが保護されます。メッシュの namespace のセキュリティーは、ServiceMeshControlPlane リソースのデータプレーンレベルで保護できます。トラフィックの暗号化接続をカスタマイズするには、アプリケーションレベルで namespace を PeerAuthentication および DestinationRule リソースで設定します。
2.13.1.1. Service Mesh 全体での厳密な mTLS の有効化 リンクのコピーリンクがクリップボードにコピーされました!
ワークロードがメッシュ外のサービスと通信しない場合は、通信を中断せずに mTLS をメッシュ全体ですぐに有効にできます。これを有効にするには、ServiceMeshControlPlane リソースで spec.security.dataPlane.mtls を true に設定します。Operator は必要なリソースを作成します。
OpenShift Container Platform Web コンソールを使用して mTLS を有効にすることもできます。
手順
- Web コンソールにログインします。
- Project メニューをクリックし、Service Mesh コントロールプレーンをインストールしたプロジェクト (例: istio-system) を選択します。
-
Operators
Installed Operators をクリックします。 - Provided APIs の Service Mesh Control Plane をクリックします。
-
ServiceMeshControlPlaneリソースの名前 (例:basic) をクリックします。 - Details ページで、Data Plane Security の Security セクションでトグルをクリックします。
2.13.1.1.1. 特定のサービスの受信接続用のサイドカーの設定 リンクのコピーリンクがクリップボードにコピーされました!
ポリシーを作成して、個別のサービスに mTLS を設定することもできます。
手順
以下のサンプルを使用して YAML ファイルを作成します。
PeerAuthentication ポリシーの例 (policy.yaml)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
<namespace>は、サービスが置かれている namespace に置き換えます。
-
以下のコマンドを実行して、サービスが置かれている namespace にリソースを作成します。先ほど作成した Policy リソースの
namespaceフィールドと一致させる必要があります。oc create -n <namespace> -f <policy.yaml>
$ oc create -n <namespace> -f <policy.yaml>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
自動 mTLS を使用しておらず、PeerAuthentication を STRICT に設定する場合は、サービスの DestinationRule リソースを作成する必要があります。
2.13.1.1.2. 送信接続用のサイドカーの設定 リンクのコピーリンクがクリップボードにコピーされました!
宛先ルールを作成し、Service Mesh がメッシュ内の他のサービスに要求を送信する際に mTLS を使用するように設定します。
手順
以下のサンプルを使用して YAML ファイルを作成します。
DestinationRule の例 (destination-rule.yaml)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
<namespace>は、サービスが置かれている namespace に置き換えます。
-
以下のコマンドを実行して、サービスが置かれている namespace にリソースを作成します。先ほど作成した
DestinationRuleリソースのnamespaceフィールドと一致させる必要があります。oc create -n <namespace> -f <destination-rule.yaml>
$ oc create -n <namespace> -f <destination-rule.yaml>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.13.1.1.3. 最小および最大のプロトコルバージョンの設定 リンクのコピーリンクがクリップボードにコピーされました!
ご使用の環境の Service Mesh に暗号化されたトラフィックの特定の要件がある場合は、許可される暗号化機能を制御できます。これは、ServiceMeshControlPlane リソースに spec.security.controlPlane.tls.minProtocolVersion または spec.security.controlPlane.tls.maxProtocolVersion を設定して許可できます。Service Mesh コントロールプレーンリソースで設定されるこれらの値は、TLS 経由でセキュアに通信する場合にメッシュコンポーネントによって使用される最小および最大の TLS バージョンを定義します。
デフォルトは TLS_AUTO であり、TLS のバージョンは指定しません。
| 値 | 説明 |
|---|---|
|
| default |
|
| TLS バージョン 1.0 |
|
| TLS バージョン 1.1 |
|
| TLS バージョン 1.2 |
|
| TLS バージョン 1.3 |
手順
- Web コンソールにログインします。
- Project メニューをクリックし、Service Mesh コントロールプレーンをインストールしたプロジェクト (例: istio-system) を選択します。
-
Operators
Installed Operators をクリックします。 - Provided APIs の Service Mesh Control Plane をクリックします。
-
ServiceMeshControlPlaneリソースの名前 (例:basic) をクリックします。 - YAML タブをクリックします。
以下のコードスニペットを YAML エディターに挿入します。
minProtocolVersionの値は、TLS バージョンの値に置き換えます。この例では、最小の TLS バージョンはTLSv1_2に設定されます。ServiceMeshControlPlane スニペット
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Save をクリックします。
- Refresh をクリックし、変更が正しく更新されたことを確認します。
2.13.1.2. Kiali による暗号化の検証 リンクのコピーリンクがクリップボードにコピーされました!
Kiali コンソールは、アプリケーション、サービス、ワークロードが mTLS 暗号化を有効にしているかどうかを検証するためのいくつかの方法を提供します。
図2.5 マストヘッドアイコンメッシュワイド mTLS が有効
サービスメッシュ全体で厳密に mTLS が有効化されている場合、Kiali はマストヘッドの右側にロックアイコンを表示します。これは、メッシュ内のすべての通信に mTLS が使用されていることを意味します。
図2.6 マストヘッドアイコンメッシュワイド mTLS が一部有効
メッシュが PERMISSIVE モードに設定されているか、メッシュ全体の mTLS 設定にエラーが発生している場合、Kiali は中空ロックアイコンを表示します。
図2.7 セキュリティーバッジ
Graph ページには、mTLS が有効であることを示すために、グラフの端に Security バッジを表示するオプションがあります。グラフにセキュリティーバッジを表示するには、Display メニューの Show Badges で Security チェックボックスをオンにします。エッジにロックアイコンが表示されている場合は、mTLS が有効なリクエストが少なくとも 1 つ存在することを意味します。mTLS と non-mTLS の両方のリクエストがある場合、サイドパネルには mTLS を使用するリクエストのパーセンテージが表示されます。
Applications Detail Overview ページでは、mTLS が有効なリクエストが 1 つ以上存在するグラフの端に Security アイコンが表示されます。
Workloads Detail Overview ページでは、mTLS が有効なリクエストが 1 つ以上存在するグラフの端に Security アイコンが表示されます。
Services Detail Overview ページでは、mTLS が有効なリクエストが 1 つ以上存在するグラフの端に Security アイコンが表示されます。また、Kiali では、mTLS を設定したポートの横の Network セクションにロックアイコンが表示されることに注意してください。
2.13.2. ロールベースアクセス制御 (RBAC) の設定 リンクのコピーリンクがクリップボードにコピーされました!
ロールベースアクセス制御 (RBAC) オブジェクトは、ユーザーまたはサービスがプロジェクト内で所定のアクションを実行することが許可されるかどうかを決定します。メッシュでワークロードのメッシュ全体、namespace 全体、およびワークロード全体のアクセス制御を定義できます。
RBAC を設定するには、アクセスを設定する namespace で AuthorizationPolicy リソースを作成します。メッシュ全体のアクセスを設定する場合は、Service Mesh コントロールプレーンをインストールしたプロジェクト (例: istio-system) を使用します。
たとえば、RBAC を使用して以下を実行するポリシーを作成できます。
- プロジェクト内通信を設定します。
- デフォルト namespace のすべてのワークロードへの完全アクセスを許可または拒否します。
- ingress ゲートウェイアクセスを許可または拒否します。
- アクセスにはトークンが必要です。
認証ポリシーには、セレクター、アクション、およびルールのリストが含まれます。
-
selectorフィールドは、ポリシーのターゲットを指定します。 -
actionフィールドは、要求を許可または拒否するかどうかを指定します。 rulesフィールドは、アクションをトリガーするタイミングを指定します。-
fromフィールドは、要求元の制約を指定します。 -
toフィールドは、要求のターゲットおよびパラメーターの制約を指定します。 -
whenフィールドは、ルールを適用する追加の条件を指定します。
-
手順
AuthorizationPolicyリソースを作成します。以下の例は、ingress-policyAuthorizationPolicyを更新して、IP アドレスが Ingress ゲートウェイにアクセスすることを拒否するリソースを示しています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow リソースを作成した後に以下のコマンドを実行して、namespace にリソースを作成します。namespace は、
AuthorizationPolicyリソースのmetadata.namespaceフィールドと一致する必要があります。oc create -n istio-system -f <filename>
$ oc create -n istio-system -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
その他の一般的な設定は、以下の例を参照してください。
2.13.2.1. プロジェクト内通信の設定 リンクのコピーリンクがクリップボードにコピーされました!
AuthorizationPolicy を使用して Service Mesh コントロールプレーンを設定し、メッシュまたはメッシュ内のサービスとの通信トラフィックを許可したり、拒否したりできます。
2.13.2.1.1. namespace 外のサービスへのアクセス制限 リンクのコピーリンクがクリップボードにコピーされました!
以下の AuthorizationPolicy リソースの例を使用して、info namespace にないソースからの要求を拒否できます。
2.13.2.1.2. allow-all およびデフォルトの deny-all 認可ポリシーの作成 リンクのコピーリンクがクリップボードにコピーされました!
以下の例は、info namespace のすべてのワークロードへの完全なアクセスを許可する allow-all 認可ポリシーを示しています。
以下の例は、info namespace のすべてのワークロードへのアクセスを拒否するポリシーを示しています。
2.13.2.2. ingress ゲートウェイへのアクセスの許可または拒否 リンクのコピーリンクがクリップボードにコピーされました!
認証ポリシーを設定し、IP アドレスに基づいて許可または拒否リストを追加できます。
2.13.2.3. JSON Web トークンを使用したアクセスの制限 リンクのコピーリンクがクリップボードにコピーされました!
JSON Web Token (JWT) を使用してメッシュにアクセスできる内容を制限できます。認証後に、ユーザーまたはサービスはそのトークンに関連付けられたルート、サービスにアクセスできます。
ワークロードでサポートされる認証方法を定義する RequestAuthentication リソースを作成します。以下の例では、http://localhost:8080/auth/realms/master で実行される JWT を受け入れます。
次に、同じ namespace に AuthorizationPolicy リソースを作成し、作成した RequestAuthentication リソースと連携させます。以下の例では、要求を httpbin ワークロードに送信する際に、JWT は Authorization ヘッダーになければなりません。
2.13.3. 暗号化スイートおよび ECDH 曲線の設定 リンクのコピーリンクがクリップボードにコピーされました!
暗号化スイートおよび ECDH 曲線 (Elliptic-curve Diffie–Hellman) は、Service Mesh のセキュリティーを保護するのに役立ちます。暗号化スイートのコンマ区切りの一覧を spec.security.controlplane.tls.cipherSuites を使用して定義し、ECDH 曲線を ServiceMeshControlPlane リソースの spec.security.controlplane.tls.ecdhCurves を使用して定義できます。これらの属性のいずれかが空の場合は、デフォルト値が使用されます。
Service Mesh が TLS 1.2 以前のバージョンを使用する場合は、cipherSuites 設定が有効になります。この設定は、TLS 1.3 でネゴシエートする場合は影響を与えません。
コンマ区切りのリストに暗号化スイートを優先度順に設定します。たとえば、ecdhCurves: CurveP256, CurveP384 は、CurveP256 を CurveP384 よりも高い優先順位として設定します。
暗号化スイートを設定する場合は、TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 または TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 のいずれかを追加する必要があります。HTTP/2 のサポートには、1 つ以上の以下の暗号スイートが必要です。
サポートされている暗号化スイートは以下になります。
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_RSA_WITH_AES_128_CBC_SHA256
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
- TLS_RSA_WITH_3DES_EDE_CBC_SHA
サポートされる ECDH 曲線は以下のとおりです。
- CurveP256
- CurveP384
- CurveP521
- X25519
2.13.4. JSON Web キーセットリゾルバー認証局の設定 リンクのコピーリンクがクリップボードにコピーされました!
ServiceMeshControlPlane (SMCP) 仕様から独自の JSON Web Key Sets (JWKS) リゾルバー認証局 (CA) を設定できます。
手順
ServiceMeshControlPlane仕様ファイルを編集します。$ oc edit smcp <smcp-name>
$ oc edit smcp <smcp-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例に示すように、
ServiceMeshControlPlane仕様でmtlsフィールドの値をtrueに設定して、データプレーンのmtlsを有効にします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を保存します。OpenShift Container Platform はそれらを自動的に適用します。
pilot-jwks-cacerts-<SMCP name> などの ConfigMap が CA .pem data を使用して作成されます。
ConfigMap pilot-jwks-cacerts-<SMCP name> の例
2.13.5. 外部認証局キーおよび証明書の追加 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトで、Red Hat OpenShift Service Mesh は自己署名ルート証明書およびキーを生成し、それらを使用してワークロード証明書に署名します。ユーザー定義の証明書およびキーを使用して、ユーザー定義のルート証明書を使用してワークロード証明書に署名することもできます。この手順では、証明書と鍵を Service Mesh に接続する例を示します。
前提条件
- 相互 TLS を有効にして Red Hat OpenShift Service Mesh をインストールし、証明書を設定する。
- この例では、Maistra リポジトリー からの証明書を使用します。実稼働環境の場合は、認証局から独自の証明書を使用します。
- Bookinfo サンプルアプリケーションをデプロイして以下の手順で結果を確認しておく。
- OpenSSL は、証明書を検証するために必要です。
2.13.5.1. 既存の証明書と鍵の追加 リンクのコピーリンクがクリップボードにコピーされました!
既存の署名 (CA) 証明書および鍵を使用するには、CA 証明書、鍵、ルート証明書を含む信頼ファイルのチェーンを作成する必要があります。対応する証明書ごとに、以下のファイル名をそのまま使用する必要があります。CA 証明書の名前は ca-cert.pem、鍵の名前は ca-key.pem、ca-cert.pem に署名するルート証明書の名前は root-cert.pem です。ワークロードで中間証明書を使用する場合は、cert-chain.pem ファイルでそれらを指定する必要があります。
-
Maistra リポジトリー のサンプル証明書をローカルに保存し、
<path>を証明書へのパスに置き換えます。 cacertという名前のシークレットを作成します。これには、入力ファイルのca-cert.pem、ca-key.pem、root-cert.pemおよびcert-chain.pemが含まれます。oc create secret generic cacerts -n istio-system --from-file=<path>/ca-cert.pem \ --from-file=<path>/ca-key.pem --from-file=<path>/root-cert.pem \ --from-file=<path>/cert-chain.pem$ oc create secret generic cacerts -n istio-system --from-file=<path>/ca-cert.pem \ --from-file=<path>/ca-key.pem --from-file=<path>/root-cert.pem \ --from-file=<path>/cert-chain.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow ServiceMeshControlPlaneリソースで、spec.security.dataPlane.mtls trueをtrueに設定し、以下の例のようにcertificateAuthorityフィールドを設定します。デフォルトのrootCADirは/etc/cacertsです。キーおよび証明書がデフォルトの場所にマウントされている場合は、privateKeyを設定する必要はありません。Service Mesh は、secret-mount ファイルから証明書およびキーを読み取ります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cacertシークレットを作成/変更/削除した後に、変更を有効にするために、Service Mesh コントロールプレーンのistiodとgatewayPod を再起動する必要があります。以下のコマンドで Pod を再起動します。oc -n istio-system delete pods -l 'app in (istiod,istio-ingressgateway, istio-egressgateway)'
$ oc -n istio-system delete pods -l 'app in (istiod,istio-ingressgateway, istio-egressgateway)'Copy to Clipboard Copied! Toggle word wrap Toggle overflow Operator は、Pod を削除した後、自動的に再作成します。
info アプリケーションの Pod を再起動し、sidecar プロキシーがシークレットの変更を取り込むようにします。以下のコマンドで Pod を再起動します。
oc -n info delete pods --all
$ oc -n info delete pods --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のような出力が表示されるはずです。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドで、Pod が作成され、準備ができたことを確認します。
oc get pods -n info
$ oc get pods -n infoCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.13.5.2. 証明書の確認 リンクのコピーリンクがクリップボードにコピーされました!
Bookinfo サンプルアプリケーションを使用して、ワークロード証明書が CA に差し込まれた証明書によって署名されていることを確認します。このプロセスでは、マシンに openssl がインストールされている必要があります。
info ワークロードから証明書を抽出するには、以下のコマンドを使用します。
sleep 60 oc -n info exec "$(oc -n bookinfo get pod -l app=productpage -o jsonpath={.items..metadata.name})" -c istio-proxy -- openssl s_client -showcerts -connect details:9080 > bookinfo-proxy-cert.txt sed -n '/-----BEGIN CERTIFICATE-----/{:start /-----END CERTIFICATE-----/!{N;b start};/.*/p}' info-proxy-cert.txt > certs.pem awk 'BEGIN {counter=0;} /BEGIN CERT/{counter++} { print > "proxy-cert-" counter ".pem"}' < certs.pem$ sleep 60 $ oc -n info exec "$(oc -n bookinfo get pod -l app=productpage -o jsonpath={.items..metadata.name})" -c istio-proxy -- openssl s_client -showcerts -connect details:9080 > bookinfo-proxy-cert.txt $ sed -n '/-----BEGIN CERTIFICATE-----/{:start /-----END CERTIFICATE-----/!{N;b start};/.*/p}' info-proxy-cert.txt > certs.pem $ awk 'BEGIN {counter=0;} /BEGIN CERT/{counter++} { print > "proxy-cert-" counter ".pem"}' < certs.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow コマンドを実行すると、作業ディレクトリーに
proxy-cert-1.pem、proxy-cert-2.pem、proxy-cert-3.pemの 3 つのファイルが作成されるはずです。ルート証明書が管理者が指定したものと同じであることを確認します。
<path>を証明書へのパスに置き換えます。openssl x509 -in <path>/root-cert.pem -text -noout > /tmp/root-cert.crt.txt
$ openssl x509 -in <path>/root-cert.pem -text -noout > /tmp/root-cert.crt.txtCopy to Clipboard Copied! Toggle word wrap Toggle overflow ターミナルウィンドウで次の構文を実行します。
openssl x509 -in ./proxy-cert-3.pem -text -noout > /tmp/pod-root-cert.crt.txt
$ openssl x509 -in ./proxy-cert-3.pem -text -noout > /tmp/pod-root-cert.crt.txtCopy to Clipboard Copied! Toggle word wrap Toggle overflow ターミナルウィンドウで以下の構文を実行して、証明書を比較します。
diff -s /tmp/root-cert.crt.txt /tmp/pod-root-cert.crt.txt
$ diff -s /tmp/root-cert.crt.txt /tmp/pod-root-cert.crt.txtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のような結果が表示されるはずです:
Files /tmp/root-cert.crt.txt and /tmp/pod-root-cert.crt.txt are identicalCA 証明書が管理者が指定したものと同じであることを確認します。
<path>を証明書へのパスに置き換えます。openssl x509 -in <path>/ca-cert.pem -text -noout > /tmp/ca-cert.crt.txt
$ openssl x509 -in <path>/ca-cert.pem -text -noout > /tmp/ca-cert.crt.txtCopy to Clipboard Copied! Toggle word wrap Toggle overflow ターミナルウィンドウで次の構文を実行します。
openssl x509 -in ./proxy-cert-2.pem -text -noout > /tmp/pod-cert-chain-ca.crt.txt
$ openssl x509 -in ./proxy-cert-2.pem -text -noout > /tmp/pod-cert-chain-ca.crt.txtCopy to Clipboard Copied! Toggle word wrap Toggle overflow ターミナルウィンドウで以下の構文を実行して、証明書を比較します。
diff -s /tmp/ca-cert.crt.txt /tmp/pod-cert-chain-ca.crt.txt
$ diff -s /tmp/ca-cert.crt.txt /tmp/pod-cert-chain-ca.crt.txtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のような結果が表示されるはずです:
Files /tmp/ca-cert.crt.txt and /tmp/pod-cert-chain-ca.crt.txt are identical.ルート証明書からワークロード証明書への証明書チェーンを確認します。
<path>を証明書へのパスに置き換えます。openssl verify -CAfile <(cat <path>/ca-cert.pem <path>/root-cert.pem) ./proxy-cert-1.pem
$ openssl verify -CAfile <(cat <path>/ca-cert.pem <path>/root-cert.pem) ./proxy-cert-1.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のような出力が表示されるはずです:
./proxy-cert-1.pem: OK
2.13.5.3. 証明書の削除 リンクのコピーリンクがクリップボードにコピーされました!
追加した証明書を削除するには、以下の手順に従います。
シークレット
cacertsを削除します。この例では、istio-systemが Service Mesh コントロールプレーンプロジェクトの名前となります。oc delete secret cacerts -n istio-system
$ oc delete secret cacerts -n istio-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow ServiceMeshControlPlaneリソースで自己署名ルート証明書を使用して Service Mesh を再デプロイします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.13.6. Service Mesh と cert-manager および istio-csr の統合について リンクのコピーリンクがクリップボードにコピーされました!
cert-manager ツールは、Kubernetes での X.509 証明書管理のソリューションです。Vault、Google Cloud Certificate Service、Let’s Encrypt などのプロバイダーなどの秘密鍵または公開鍵基盤 (PKI) とアプリケーションを統合するための統合 API を提供します。
cert-manager ツールは、証明書の有効期限が切れる前に、設定された時間に証明書の更新を試行することで、証明書が有効で最新であることを確認します。
Istio ユーザーの場合、cert-manager は、Istio プロキシーからの証明書署名要求 (CSR) を処理する認証局 (CA) サーバーである istio-csr との統合も提供します。次に、サーバーは署名を cert-manager に委任し、設定された CA サーバーに CSR を転送します。
Red Hat は、istio-csr および cert-manager との統合のサポートを提供します。Red Hat は istio-csr またはコミュニティー cert-manager コンポーネントに対する直接サポートを提供しません。ここで示すコミュニティー cert-manager の使用は、デモンストレーションのみを目的としています。
前提条件
cert-manager の次のいずれかのバージョン:
- Red Hat OpenShift 1.10 以降の cert-manager Operator
- コミュニティー cert-manager Operator 1.11 以降
- cert-manager 1.11 以降
- OpenShift Service Mesh Operator 2.4 以降
-
istio-csr0.6.0 以降
istio-csr サーバーが jetstack/cert-manager-istio-csr Helm チャートとともにインストールされているときに、すべての namespace で config map が作成されないようにするには、istio-csr.yaml ファイル内の app.controller.configmapNamespaceSelector: "maistra.io/member-of: <istio-namespace>" 設定を使用します。
2.13.6.1. cert-manager のインストール リンクのコピーリンクがクリップボードにコピーされました!
cert-manager ツールをインストールすると、TLS 証明書のライフサイクルを管理し、証明書が有効で最新であることを確認できます。環境内で Istio を実行している場合は、Istio プロキシーからの証明書署名要求 (CSR) を処理する istio-csr 認証局 (CA) サーバーをインストールすることもできます。istio-csr CA は署名を cert-manager ツールに委任し、cert-manager ツールは設定された CA に委任します。
手順
ルートクラスターの発行者を作成します。
次の例のように
cluster-issuerオブジェクトを作成します。cluster-issuer.yamlの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記root-caがクラスター発行者であるため、selfsigned-root-issuerの発行者とroot-ca証明書の namespace はcert-managerです。そのため、cert-manager は参照されるシークレットを独自の namespace で検索します。Red Hat OpenShift の cert-manager Operator の場合、namespace の名前はcert-managerです。次のコマンドを使用してオブジェクトを作成します。
oc apply -f cluster-issuer.yaml
$ oc apply -f cluster-issuer.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例のように
istio-caオブジェクトを作成します。istio-ca.yamlの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを使用してオブジェクトを作成します。
oc apply -n istio-system -f istio-ca.yaml
$ oc apply -n istio-system -f istio-ca.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
istio-csrをインストールします。helm install istio-csr jetstack/cert-manager-istio-csr \ -n istio-system \ -f deploy/examples/cert-manager/istio-csr/istio-csr.yaml$ helm install istio-csr jetstack/cert-manager-istio-csr \ -n istio-system \ -f deploy/examples/cert-manager/istio-csr/istio-csr.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow istio-csr.yamlの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow SMCP をデプロイメントします。
oc apply -f mesh.yaml -n istio-system
$ oc apply -f mesh.yaml -n istio-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例
mesh.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
security.identity.type: ThirdParty は security.certificateAuthority.type: cert-manager が設定されている場合に設定する必要があります。
検証
サンプル httpbin サービスと sleep アプリを使用して、イングレスゲートウェイからの mTLS トラフィックをチェックし、cert-manager ツールがインストールされていることを確認します。
HTTP アプリと
sleepアプリをデプロイします。oc new-project <namespace>
$ oc new-project <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f https://raw.githubusercontent.com/maistra/istio/maistra-2.4/samples/httpbin/httpbin.yaml
$ oc apply -f https://raw.githubusercontent.com/maistra/istio/maistra-2.4/samples/httpbin/httpbin.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f https://raw.githubusercontent.com/maistra/istio/maistra-2.4/samples/sleep/sleep.yaml
$ oc apply -f https://raw.githubusercontent.com/maistra/istio/maistra-2.4/samples/sleep/sleep.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow sleepがhttpbinサービスにアクセスできることを確認します。oc exec "$(oc get pod -l app=sleep -n <namespace> \ -o jsonpath={.items..metadata.name})" -c sleep -n <namespace> -- \ curl http://httpbin.<namespace>:8000/ip -s -o /dev/null \ -w "%{http_code}\n"$ oc exec "$(oc get pod -l app=sleep -n <namespace> \ -o jsonpath={.items..metadata.name})" -c sleep -n <namespace> -- \ curl http://httpbin.<namespace>:8000/ip -s -o /dev/null \ -w "%{http_code}\n"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
200
200Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress ゲートウェイから
httpbinサービスへの mTLS トラフィックを確認します。oc apply -n <namespace> -f https://raw.githubusercontent.com/maistra/istio/maistra-2.4/samples/httpbin/httpbin-gateway.yaml
$ oc apply -n <namespace> -f https://raw.githubusercontent.com/maistra/istio/maistra-2.4/samples/httpbin/httpbin-gateway.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow istio-ingressgatewayルートを取得します。INGRESS_HOST=$(oc -n istio-system get routes istio-ingressgateway -o jsonpath='{.spec.host}')INGRESS_HOST=$(oc -n istio-system get routes istio-ingressgateway -o jsonpath='{.spec.host}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress ゲートウェイから
httpbinサービスへの mTLS トラフィックを確認します。curl -s -I http://$INGRESS_HOST/headers -o /dev/null -w "%{http_code}" -s$ curl -s -I http://$INGRESS_HOST/headers -o /dev/null -w "%{http_code}" -sCopy to Clipboard Copied! Toggle word wrap Toggle overflow