1.13. セキュリティー
サービスメッシュアプリケーションが複雑な配列のマイクロサービスで構築されている場合、Red Hat OpenShift Service Mesh を使用してそれらのサービス間の通信のセキュリティーをカスタマイズできます。Service Mesh のトラフィック管理機能と共に OpenShift Container Platform のインフラストラクチャーを使用すると、アプリケーションの複雑性を管理し、マイクロサービスのセキュリティーを確保できるようにします。
作業を開始する前に
プロジェクトがある場合は、プロジェクトを ServiceMeshMemberRoll
リソース に追加します。
プロジェクトがない場合は、Bookinfo サンプルアプリケーション をインストールし、これを ServiceMeshMemberRoll
リソースに追加します。サンプルアプリケーションは、セキュリティーの概念を説明するのに役立ちます。
1.13.1. Mutual Transport Layer Security (mTLS) について
Mutual Transport Layer Security (mTLS) は、二者が相互認証できるようにするプロトコルです。これは、一部のプロトコル (IKE、SSH) での認証のデフォルトモードであり、他のプロトコル (TLS) ではオプションになります。mTLS は、アプリケーションやサービスコードを変更せずに使用できます。TLS は、サービスメッシュインフラストラクチャーおよび 2 つのサイドカープロキシー間で完全に処理されます。
デフォルトで、Red Hat OpenShift Service Mesh の mTLS は有効になっており、Permissive モードに設定されます。この場合、Service Mesh のサイドカーは、プレーンテキストのトラフィックと mTLS を使用して暗号化される接続の両方を受け入れます。メッシュのサービスがメッシュ外のサービスと通信している場合は厳密な mTLS によりサービス間の通信に障害が発生する可能性があります。ワークロードを Service Mesh に移行する間に Permissive モードを使用します。次に、メッシュ、namespace、またはアプリケーションで厳密な mTLS を有効にできます。
Service Mesh コントロールプレーンのレベルでメッシュ全体で mTLS を有効にすると、アプリケーションとワークロードを書き換えずにサービスメッシュ内のすべてのトラフィックのセキュリティーが保護されます。メッシュの namespace のセキュリティーは、ServiceMeshControlPlane
リソースのデータプレーンレベルで保護できます。トラフィックの暗号化接続をカスタマイズするには、アプリケーションレベルで namespace を PeerAuthentication
および DestinationRule
リソースで設定します。
1.13.1.1. サービスメッシュ全体での厳密な mTLS の有効化
ワークロードがメッシュ外のサービスと通信しない場合は、通信を中断せずに mTLS をメッシュ全体ですぐに有効にできます。これを有効にするには、ServiceMeshControlPlane
リソースで spec.security.dataPlane.mtls
を true
に設定します。Operator は必要なリソースを作成します。
apiVersion: maistra.io/v2 kind: ServiceMeshControlPlane spec: version: v2.4 security: dataPlane: mtls: true
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 セクションでトグルをクリックします。
1.13.1.1.1. 特定のサービスの受信接続用のサイドカーの設定
ポリシーを作成して、個別のサービスに mTLS を設定することもできます。
手順
以下のサンプルを使用して YAML ファイルを作成します。
PeerAuthentication ポリシーの例 (policy.yaml)
apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: default namespace: <namespace> spec: mtls: mode: STRICT
-
<namespace>
は、サービスが置かれている namespace に置き換えます。
-
以下のコマンドを実行して、サービスが置かれている namespace にリソースを作成します。先ほど作成した Policy リソースの
namespace
フィールドと一致させる必要があります。$ oc create -n <namespace> -f <policy.yaml>
自動 mTLS を使用しておらず、PeerAuthentication
を STRICT に設定する場合は、サービスの DestinationRule
リソースを作成する必要があります。
1.13.1.1.2. 送信接続用のサイドカーの設定
宛先ルールを作成し、Service Mesh がメッシュ内の他のサービスに要求を送信する際に mTLS を使用するように設定します。
手順
以下のサンプルを使用して YAML ファイルを作成します。
destinationRule の例 (destination-rule.yaml)
apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: default namespace: <namespace> spec: host: "*.<namespace>.svc.cluster.local" trafficPolicy: tls: mode: ISTIO_MUTUAL
-
<namespace>
は、サービスが置かれている namespace に置き換えます。
-
以下のコマンドを実行して、サービスが置かれている namespace にリソースを作成します。先ほど作成した
DestinationRule
リソースのnamespace
フィールドと一致させる必要があります。$ oc create -n <namespace> -f <destination-rule.yaml>
1.13.1.1.3. 最小および最大のプロトコルバージョンの設定
ご使用の環境のサービスメッシュに暗号化されたトラフィックの特定の要件がある場合は、許可される暗号化機能を制御できます。これは、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 スニペット
kind: ServiceMeshControlPlane spec: security: controlPlane: tls: minProtocolVersion: TLSv1_2
- Save をクリックします。
- Refresh をクリックし、変更が正しく更新されたことを確認します。
1.13.1.2. Kiali による暗号化の検証
Kiali コンソールは、アプリケーション、サービス、ワークロードが mTLS 暗号化を有効にしているかどうかを検証するためのいくつかの方法を提供します。
図1.5 マストヘッドアイコン メッシュワイド mTLS が有効
![mTLS enabled](https://access.redhat.com/webassets/avalon/d/OpenShift_Container_Platform-4.10-Service_Mesh-ja-JP/images/d36101afefb618f85c2e7cc2b0db104a/ossm-kiali-masthead-mtls-enabled.png)
サービスメッシュ全体で厳密に mTLS が有効化されている場合、Kiali はマストヘッドの右側にロックアイコンを表示します。これは、メッシュ内のすべての通信に mTLS が使用されていることを意味します。
図1.6 マストヘッドアイコン メッシュワイド mTLS が一部有効
![mTLS partially enabled](https://access.redhat.com/webassets/avalon/d/OpenShift_Container_Platform-4.10-Service_Mesh-ja-JP/images/fec43ee345427929dedb0ba5edc31c3d/ossm-kiali-masthead-mtls-partial.png)
メッシュが PERMISSIVE
モードに設定されているか、メッシュ全体の mTLS 設定にエラーが発生している場合、Kiali は中空ロックアイコンを表示します。
図1.7 セキュリティーバッジ
![セキュリティーバッジ](https://access.redhat.com/webassets/avalon/d/OpenShift_Container_Platform-4.10-Service_Mesh-ja-JP/images/a1e3c6682f7fd5de7e8c650c569be46d/ossm-kiali-graph-badge-security.png)
Graph ページには、mTLS が有効であることを示すために、グラフの端に Security バッジを表示するオプションがあります。グラフにセキュリティーバッジを表示するには、Display メニューの Show Badges で Security チェックボックスをオンにします。エッジにロックアイコンが表示されている場合は、mTLS が有効なリクエストが少なくとも 1 つ存在することを意味します。mTLS と non-TLS の両方のリクエストがある場合、サイドパネルには mTLS を使用するリクエストのパーセンテージが表示されます。
Applications Detail Overview ページでは、mTLS が有効なリクエストが 1 つ以上存在するグラフの端に Security アイコンが表示されます。
Workloads Detail Overview ページでは、mTLS が有効なリクエストが 1 つ以上存在するグラフの端に Security アイコンが表示されます。
Services Detail Overview ページでは、mTLS が有効なリクエストが 1 つ以上存在するグラフの端に Security アイコンが表示されます。また、Kiali では、mTLS を設定したポートの横の Network セクションにロックアイコンが表示されることに注意してください。
1.13.2. ロールベースアクセス制御 (RBAC) の設定
Role-based Access Control (RBAC: ロールベースアクセス制御) オブジェクトは、ユーザーまたはサービスがプロジェクト内で所定のアクションを実行することが許可されるかどうかを決定します。メッシュでワークロードのメッシュ全体、namespace 全体、およびワークロード全体のアクセス制御を定義できます。
RBAC を設定するには、アクセスを設定する namespace で AuthorizationPolicy
リソースを作成します。メッシュ全体のアクセスを設定する場合は、Service Mesh コントロールプレーンをインストールしたプロジェクト (例: istio-system
) を使用します。
たとえば、RBAC を使用して以下を実行するポリシーを作成できます。
- プロジェクト内通信を設定します。
- デフォルト namespace のすべてのワークロードへの完全アクセスを許可または拒否します。
- ingress ゲートウェイアクセスを許可または拒否します。
- アクセスにはトークンが必要です。
認証ポリシーには、セレクター、アクション、およびルールの一覧が含まれます。
-
selector
フィールドは、ポリシーのターゲットを指定します。 -
action
フィールドは、要求を許可または拒否するかどうかを指定します。 rules
フィールドは、アクションをトリガーするタイミングを指定します。-
from
フィールドは、要求元の制約を指定します。 -
to
フィールドは、要求のターゲットおよびパラメーターの制約を指定します。 -
when
フィールドは、ルールを適用する追加の条件を指定します。
-
手順
AuthorizationPolicy
リソースを作成します。以下の例は、ingress-policyAuthorizationPolicy
を更新して、IP アドレスが Ingress ゲートウェイにアクセスすることを拒否するリソースを示しています。apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: ingress-policy namespace: istio-system spec: selector: matchLabels: app: istio-ingressgateway action: DENY rules: - from: - source: ipBlocks: ["1.2.3.4"]
リソースを作成した後に以下のコマンドを実行して、namespace にリソースを作成します。namespace は、
AuthorizationPolicy
リソースのmetadata.namespace
フィールドと一致する必要があります。$ oc create -n istio-system -f <filename>
次のステップ
その他の一般的な設定は、以下の例を参照してください。
1.13.2.1. プロジェクト内通信の設定
AuthorizationPolicy
を使用して Service Mesh コントロールプレーンを設定し、メッシュまたはメッシュ内のサービスとの通信トラフィックを許可したり、拒否したりできます。
1.13.2.1.1. namespace 外のサービスへのアクセス制限
以下の AuthorizationPolicy
リソースの例を使用して、info
namespace にないソースからの要求を拒否できます。
apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: httpbin-deny namespace: info spec: selector: matchLabels: app: httpbin version: v1 action: DENY rules: - from: - source: notNamespaces: ["info"]
1.13.2.1.2. allow-all およびデフォルトの deny-all 認可ポリシーの作成
以下の例は、info
namespace のすべてのワークロードへの完全なアクセスを許可する allow-all 認可ポリシーを示しています。
apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: allow-all namespace: info spec: action: ALLOW rules: - {}
以下の例は、info
namespace のすべてのワークロードへのアクセスを拒否するポリシーを示しています。
apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: deny-all namespace: info spec: {}
1.13.2.2. ingress ゲートウェイへのアクセスの許可または拒否
認証ポリシーを設定し、IP アドレスに基づいて許可または拒否リストを追加できます。
apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: ingress-policy namespace: istio-system spec: selector: matchLabels: app: istio-ingressgateway action: ALLOW rules: - from: - source: ipBlocks: ["1.2.3.4", "5.6.7.0/24"]
1.13.2.3. JSON Web トークンを使用したアクセスの制限
JSON Web Token (JWT) を使用してメッシュにアクセスできる内容を制限できます。認証後に、ユーザーまたはサービスはそのトークンに関連付けられたルート、サービスにアクセスできます。
ワークロードでサポートされる認証方法を定義する RequestAuthentication
リソースを作成します。以下の例では、http://localhost:8080/auth/realms/master
で実行される JWT を受け入れます。
apiVersion: "security.istio.io/v1beta1" kind: "RequestAuthentication" metadata: name: "jwt-example" namespace: info spec: selector: matchLabels: app: httpbin jwtRules: - issuer: "http://localhost:8080/auth/realms/master" jwksUri: "http://keycloak.default.svc:8080/auth/realms/master/protocol/openid-connect/certs"
次に、同じ namespace に AuthorizationPolicy
リソースを作成し、作成した RequestAuthentication
リソースと連携させます。以下の例では、要求を httpbin
ワークロードに送信する際に、JWT は Authorization
ヘッダーになければなりません。
apiVersion: "security.istio.io/v1beta1" kind: "AuthorizationPolicy" metadata: name: "frontend-ingress" namespace: info spec: selector: matchLabels: app: httpbin action: DENY rules: - from: - source: notRequestPrincipals: ["*"]
1.13.3. 暗号化スイートおよび ECDH 曲線の設定
暗号化スイートおよび ECDH 曲線 (Elliptic-curve Diffie–Hellman) は、サービスメッシュのセキュリティーを保護するのに役立ちます。暗号化スイートのコンマ区切りの一覧を spec.security.controlplane.tls.cipherSuites
を使用して定義し、 ECDH 曲線を ServiceMeshControlPlane
リソースの spec.security.controlplane.tls.ecdhCurves
を使用して定義できます。これらの属性のいずれかが空の場合は、デフォルト値が使用されます。
サービスメッシュが 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
1.13.4. 外部認証局キーおよび証明書の追加
デフォルトで、Red Hat OpenShift Service Mesh は自己署名ルート証明書およびキーを生成し、それらを使用してワークロード証明書に署名します。ユーザー定義の証明書およびキーを使用して、ユーザー定義のルート証明書を使用してワークロード証明書に署名することもできます。このタスクは、証明書およびキーを Service Mesh にプラグインするサンプルを示しています。
前提条件
- 相互 TLS を有効にして Red Hat OpenShift Service Mesh をインストールし、証明書を設定する。
- この例では、Maistra リポジトリー からの証明書を使用します。実稼働環境の場合は、認証局から独自の証明書を使用します。
- Bookinfo サンプルアプリケーションをデプロイして以下の手順で結果を確認しておく。
- OpenSSL は、証明書を検証するために必要です。
1.13.4.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
ServiceMeshControlPlane
リソースで、spec.security.dataPlane.mtls true
をtrue
に設定し、以下の例のようにcertificateAuthority
フィールドを設定します。デフォルトのrootCADir
は/etc/cacerts
です。キーおよび証明書がデフォルトの場所にマウントされている場合は、privateKey
を設定する必要はありません。Service Mesh は、secret-mount ファイルから証明書およびキーを読み取ります。apiVersion: maistra.io/v2 kind: ServiceMeshControlPlane spec: security: dataPlane: mtls: true certificateAuthority: type: Istiod istiod: type: PrivateKey privateKey: rootCADir: /etc/cacerts
cacert
シークレットを作成/変更/削除した後に、変更を有効にするために、Service Mesh コントロールプレーンのistiod
とgateway
Pod を再起動する必要があります。以下のコマンドで Pod を再起動します。$ oc -n istio-system delete pods -l 'app in (istiod,istio-ingressgateway, istio-egressgateway)'
Operator は、Pod を削除した後、自動的に再作成します。
info アプリケーションの Pod を再起動し、sidecar プロキシーがシークレットの変更を取り込むようにします。以下のコマンドで Pod を再起動します。
$ oc -n info delete pods --all
以下のような出力が表示されるはずです。
pod "details-v1-6cd699df8c-j54nh" deleted pod "productpage-v1-5ddcb4b84f-mtmf2" deleted pod "ratings-v1-bdbcc68bc-kmng4" deleted pod "reviews-v1-754ddd7b6f-lqhsv" deleted pod "reviews-v2-675679877f-q67r2" deleted pod "reviews-v3-79d7549c7-c2gjs" deleted
以下のコマンドで、Pod が作成され、準備ができたことを確認します。
$ oc get pods -n info
1.13.4.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
コマンドを実行すると、作業ディレクトリーに
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 ./proxy-cert-3.pem -text -noout > /tmp/pod-root-cert.crt.txt
ターミナルウィンドウで以下の構文を実行して、証明書を比較します。
$ diff -s /tmp/root-cert.crt.txt /tmp/pod-root-cert.crt.txt
以下のような結果が表示されるはずです:
Files /tmp/root-cert.crt.txt and /tmp/pod-root-cert.crt.txt are identical
CA 証明書が管理者が指定したものと同じであることを確認します。
<path>
を証明書へのパスに置き換えます。$ openssl x509 -in <path>/ca-cert.pem -text -noout > /tmp/ca-cert.crt.txt
ターミナルウィンドウで次の構文を実行します。
$ openssl x509 -in ./proxy-cert-2.pem -text -noout > /tmp/pod-cert-chain-ca.crt.txt
ターミナルウィンドウで以下の構文を実行して、証明書を比較します。
$ diff -s /tmp/ca-cert.crt.txt /tmp/pod-cert-chain-ca.crt.txt
以下のような結果が表示されるはずです:
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
以下のような出力が表示されるはずです:
./proxy-cert-1.pem: OK
1.13.4.3. 証明書の削除
追加した証明書を削除するには、以下の手順に従います。
シークレット
cacerts
を削除します。この例では、istio-system
が Service Mesh コントロールプレーンプロジェクトの名前となります。$ oc delete secret cacerts -n istio-system
ServiceMeshControlPlane
リソースで自己署名ルート証明書を使用して Service Mesh を再デプロイします。apiVersion: maistra.io/v2 kind: ServiceMeshControlPlane spec: security: dataPlane: mtls: true
1.13.5. Service Mesh と cert-manager および istio-csr の統合について
cert-manager ツールは、Kubernetes での X.509 証明書管理のソリューションです。Vault、Google Cloud Certificate Authority 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-csr
0.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>"
。
1.13.5.1. cert-manager のインストール
cert-manager
ツールをインストールすると、TLS 証明書のライフサイクルを管理し、証明書が有効で最新であることを確認できます。環境内で Istio を実行している場合は、Istio プロキシーからの証明書署名要求 (CSR) を処理する istio-csr
認証局 (CA) サーバーをインストールすることもできます。istio-csr
CA は署名を cert-manager
ツールに委任し、cert-manager ツールは設定された CA に委任します。
手順
ルートクラスターの発行者を作成します。
$ oc apply -f cluster-issuer.yaml
$ oc apply -n istio-system -f istio-ca.yaml
cluster-issuer.yaml
の例apiVersion: cert-manager.io/v1 kind: Issuer metadata: name: selfsigned-root-issuer namespace: cert-manager spec: selfSigned: {} --- apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: root-ca namespace: cert-manager spec: isCA: true duration: 21600h # 900d secretName: root-ca commonName: root-ca.my-company.net subject: organizations: - my-company.net issuerRef: name: selfsigned-root-issuer kind: Issuer group: cert-manager.io --- apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: root-ca spec: ca: secretName: root-ca
istio-ca.yaml
の例apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: istio-ca namespace: istio-system spec: isCA: true duration: 21600h secretName: istio-ca commonName: istio-ca.my-company.net subject: organizations: - my-company.net issuerRef: name: root-ca kind: ClusterIssuer group: cert-manager.io --- apiVersion: cert-manager.io/v1 kind: Issuer metadata: name: istio-ca namespace: istio-system spec: ca: secretName: istio-ca
注記root-ca
はクラスター発行者であるため、selfsigned-root-issuer
発行者およびroot-ca
証明書の namespace はcert-manager
です。そのため、cert-manager は自身の名前空間で参照される秘密を探します。Red Hat OpenShift の cert-manager Operator の場合、独自の namespace はcert-manager
です。istio-csr
をインストールします。$ helm install istio-csr jetstack/cert-manager-istio-csr \ -n istio-system \ -f deploy/examples/cert-manager/istio-csr/istio-csr.yaml
istio-csr.yaml
の例replicaCount: 2 image: repository: quay.io/jetstack/cert-manager-istio-csr tag: v0.6.0 pullSecretName: "" app: certmanager: namespace: istio-system issuer: group: cert-manager.io kind: Issuer name: istio-ca controller: configmapNamespaceSelector: "maistra.io/member-of=istio-system" leaderElectionNamespace: istio-system istio: namespace: istio-system revisions: ["basic"] server: maxCertificateDuration: 5m tls: certificateDNSNames: # This DNS name must be set in the SMCP spec.security.certificateAuthority.cert-manager.address - cert-manager-istio-csr.istio-system.svc
SMCP をデプロイメントします。
$ oc apply -f mesh.yaml -n istio-system
例
mesh.yaml
apiVersion: maistra.io/v2 kind: ServiceMeshControlPlane metadata: name: basic spec: addons: grafana: enabled: false kiali: enabled: false prometheus: enabled: false proxy: accessLogging: file: name: /dev/stdout security: certificateAuthority: cert-manager: address: cert-manager-istio-csr.istio-system.svc:443 type: cert-manager dataPlane: mtls: true identity: type: ThirdParty tracing: type: None --- apiVersion: maistra.io/v1 kind: ServiceMeshMemberRoll metadata: name: default spec: members: - httpbin - sleep
security.identity.type: ThirdParty
は security.certificateAuthority.type: cert-manager
が設定されている場合に設定する必要があります。
検証
サンプル httpbin
サービスと sleep
アプリを使用して、イングレスゲートウェイからの mTLS トラフィックをチェックし、cert-manager
ツールがインストールされていることを確認します。
HTTP アプリと
sleep
アプリをデプロイします。$ oc new-project <namespace>
$ 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/sleep/sleep.yaml
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"
出力例:
200
Ingress ゲートウェイから
httpbin
サービスへの mTLS トラフィックを確認します。$ oc apply -n <namespace> -f https://raw.githubusercontent.com/maistra/istio/maistra-2.4/samples/httpbin/httpbin-gateway.yaml
istio-ingressgateway
ルートを取得します。INGRESS_HOST=$(oc -n istio-system get routes istio-ingressgateway -o jsonpath='{.spec.host}')
Ingress ゲートウェイから
httpbin
サービスへの mTLS トラフィックを確認します。$ curl -s -I http://$INGRESS_HOST/headers -o /dev/null -w "%{http_code}" -s
1.13.6. 関連情報
OpenShift Container Platform の cert-manager Operator のインストール方法は、Red Hat OpenShift の cert-manager Operator のインストール を参照してください。