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.mtlstrue に設定します。Operator は必要なリソースを作成します。

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
spec:
  version: v2.6
  security:
    dataPlane:
      mtls: true

OpenShift Container Platform Web コンソールを使用して mTLS を有効にすることもできます。

手順

  1. Web コンソールにログインします。
  2. Project メニューをクリックし、Service Mesh コントロールプレーンをインストールしたプロジェクト (例: istio-system) を選択します。
  3. Operators Installed Operators をクリックします。
  4. Provided APIsService Mesh Control Plane をクリックします。
  5. ServiceMeshControlPlane リソースの名前 (例: basic) をクリックします。
  6. Details ページで、Data Plane SecuritySecurity セクションでトグルをクリックします。
2.13.1.1.1. 特定のサービスの受信接続用のサイドカーの設定

ポリシーを作成して、個別のサービスに mTLS を設定することもできます。

手順

  1. 以下のサンプルを使用して YAML ファイルを作成します。

    PeerAuthentication ポリシーの例 (policy.yaml)

    apiVersion: security.istio.io/v1beta1
    kind: PeerAuthentication
    metadata:
      name: default
      namespace: <namespace>
    spec:
      mtls:
        mode: STRICT

    1. <namespace> は、サービスが置かれている namespace に置き換えます。
  2. 以下のコマンドを実行して、サービスが置かれている namespace にリソースを作成します。先ほど作成した Policy リソースの namespace フィールドと一致させる必要があります。

    $ oc create -n <namespace> -f <policy.yaml>
注記

自動 mTLS を使用しておらず、PeerAuthentication を STRICT に設定する場合は、サービスの DestinationRule リソースを作成する必要があります。

2.13.1.1.2. 送信接続用のサイドカーの設定

宛先ルールを作成し、Service Mesh がメッシュ内の他のサービスに要求を送信する際に mTLS を使用するように設定します。

手順

  1. 以下のサンプルを使用して 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

    1. <namespace> は、サービスが置かれている namespace に置き換えます。
  2. 以下のコマンドを実行して、サービスが置かれている namespace にリソースを作成します。先ほど作成した DestinationRule リソースの namespace フィールドと一致させる必要があります。

    $ oc create -n <namespace> -f <destination-rule.yaml>
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 のバージョンは指定しません。

表2.5 有効な値
説明

TLS_AUTO

default

TLSv1_0

TLS バージョン 1.0

TLSv1_1

TLS バージョン 1.1

TLSv1_2

TLS バージョン 1.2

TLSv1_3

TLS バージョン 1.3

手順

  1. Web コンソールにログインします。
  2. Project メニューをクリックし、Service Mesh コントロールプレーンをインストールしたプロジェクト (例: istio-system) を選択します。
  3. Operators Installed Operators をクリックします。
  4. Provided APIsService Mesh Control Plane をクリックします。
  5. ServiceMeshControlPlane リソースの名前 (例: basic) をクリックします。
  6. YAML タブをクリックします。
  7. 以下のコードスニペットを YAML エディターに挿入します。minProtocolVersion の値は、TLS バージョンの値に置き換えます。この例では、最小の TLS バージョンは TLSv1_2 に設定されます。

    ServiceMeshControlPlane スニペット

    kind: ServiceMeshControlPlane
    spec:
      security:
        controlPlane:
          tls:
            minProtocolVersion: TLSv1_2

  8. Save をクリックします。
  9. Refresh をクリックし、変更が正しく更新されたことを確認します。

2.13.1.2. Kiali による暗号化の検証

Kiali コンソールは、アプリケーション、サービス、ワークロードが mTLS 暗号化を有効にしているかどうかを検証するためのいくつかの方法を提供します。

図2.5 マストヘッドアイコンメッシュワイド mTLS が有効

mTLS enabled

サービスメッシュ全体で厳密に mTLS が有効化されている場合、Kiali はマストヘッドの右側にロックアイコンを表示します。これは、メッシュ内のすべての通信に mTLS が使用されていることを意味します。

図2.6 マストヘッドアイコンメッシュワイド mTLS が一部有効

mTLS partially enabled

メッシュが PERMISSIVE モードに設定されているか、メッシュ全体の mTLS 設定にエラーが発生している場合、Kiali は中空ロックアイコンを表示します。

図2.7 セキュリティーバッジ

セキュリティーバッジ

Graph ページには、mTLS が有効であることを示すために、グラフの端に Security バッジを表示するオプションがあります。グラフにセキュリティーバッジを表示するには、Display メニューの Show BadgesSecurity チェックボックスをオンにします。エッジにロックアイコンが表示されている場合は、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 フィールドは、ルールを適用する追加の条件を指定します。

手順

  1. AuthorizationPolicy リソースを作成します。以下の例は、ingress-policy AuthorizationPolicy を更新して、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"]
  2. リソースを作成した後に以下のコマンドを実行して、namespace にリソースを作成します。namespace は、AuthorizationPolicy リソースの metadata.namespace フィールドと一致する必要があります。

    $ oc create -n istio-system -f <filename>

次のステップ

その他の一般的な設定は、以下の例を参照してください。

2.13.2.1. プロジェクト内通信の設定

AuthorizationPolicy を使用して Service Mesh コントロールプレーンを設定し、メッシュまたはメッシュ内のサービスとの通信トラフィックを許可したり、拒否したりできます。

2.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"]
2.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:
  {}

2.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"]

2.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: ["*"]

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 は、CurveP256CurveP384 よりも高い優先順位として設定します。

注記

暗号化スイートを設定する場合は、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) を設定できます。

手順

  1. ServiceMeshControlPlane 仕様ファイルを編集します。

    $ oc edit smcp <smcp-name>
  2. 次の例に示すように、ServiceMeshControlPlane 仕様で mtls フィールドの値を true に設定して、データプレーンの mtls を有効にします。

    spec:
      security:
        dataPlane:
            mtls: true # enable mtls for data plane
        # JWKSResolver extra CA
        # PEM-encoded certificate content to trust an additional CA
        jwksResolverCA: |
            -----BEGIN CERTIFICATE-----
            [...]
            [...]
            -----END CERTIFICATE-----
    ...
  3. 変更を保存します。OpenShift Container Platform はそれらを自動的に適用します。

pilot-jwks-cacerts-<SMCP name> などの ConfigMap が CA .pem data を使用して作成されます。

ConfigMap pilot-jwks-cacerts-<SMCP name> の例

kind: ConfigMap
apiVersion: v1
data:
  extra.pem: |
      -----BEGIN CERTIFICATE-----
      [...]
      [...]
      -----END CERTIFICATE-----

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 ファイルでそれらを指定する必要があります。

  1. Maistra リポジトリー のサンプル証明書をローカルに保存し、<path> を証明書へのパスに置き換えます。
  2. cacert という名前のシークレットを作成します。これには、入力ファイルの ca-cert.pemca-key.pemroot-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
  3. ServiceMeshControlPlane リソースで、spec.security.dataPlane.mtls truetrue に設定し、以下の例のように 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
  4. cacert シークレットを作成/変更/削除した後に、変更を有効にするために、Service Mesh コントロールプレーンの istiodgateway Pod を再起動する必要があります。以下のコマンドで Pod を再起動します。

    $ oc -n istio-system delete pods -l 'app in (istiod,istio-ingressgateway, istio-egressgateway)'

    Operator は、Pod を削除した後、自動的に再作成します。

  5. 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
  6. 以下のコマンドで、Pod が作成され、準備ができたことを確認します。

    $ oc get pods -n info

2.13.5.2. 証明書の確認

Bookinfo サンプルアプリケーションを使用して、ワークロード証明書が CA に差し込まれた証明書によって署名されていることを確認します。このプロセスでは、マシンに openssl がインストールされている必要があります。

  1. 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.pemproxy-cert-2.pemproxy-cert-3.pem の 3 つのファイルが作成されるはずです。

  2. ルート証明書が管理者が指定したものと同じであることを確認します。<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

  3. 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.

  4. ルート証明書からワークロード証明書への証明書チェーンを確認します。<path> を証明書へのパスに置き換えます。

    $ openssl verify -CAfile <(cat <path>/ca-cert.pem <path>/root-cert.pem) ./proxy-cert-1.pem

    以下のような出力が表示されるはずです: ./proxy-cert-1.pem: OK

2.13.5.3. 証明書の削除

追加した証明書を削除するには、以下の手順に従います。

  1. シークレット cacerts を削除します。この例では、istio-system が Service Mesh コントロールプレーンプロジェクトの名前となります。

    $ oc delete secret cacerts -n istio-system
  2. ServiceMeshControlPlane リソースで自己署名ルート証明書を使用して Service Mesh を再デプロイします。

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    spec:
      security:
        dataPlane:
          mtls: true

2.13.6. 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>" 設定を使用します。

2.13.6.1. cert-manager のインストール

cert-manager ツールをインストールすると、TLS 証明書のライフサイクルを管理し、証明書が有効で最新であることを確認できます。環境内で Istio を実行している場合は、Istio プロキシーからの証明書署名要求 (CSR) を処理する istio-csr 認証局 (CA) サーバーをインストールすることもできます。istio-csr CA は署名を cert-manager ツールに委任し、cert-manager ツールは設定された CA に委任します。

手順

  1. ルートクラスターの発行者を作成します。

    1. 次の例のように cluster-issuer オブジェクトを作成します。

      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

      注記

      root-ca がクラスター発行者であるため、selfsigned-root-issuer の発行者と root-ca 証明書の namespace は cert-manager です。そのため、cert-manager は参照されるシークレットを独自の namespace で検索します。Red Hat OpenShift の cert-manager Operator の場合、namespace の名前は cert-manager です。

    2. 次のコマンドを使用してオブジェクトを作成します。

      $ oc apply -f cluster-issuer.yaml
    3. 次の例のように istio-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

    4. 次のコマンドを使用してオブジェクトを作成します。

      $ oc apply -n istio-system -f istio-ca.yaml
  2. 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

  3. 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: ThirdPartysecurity.certificateAuthority.type: cert-manager が設定されている場合に設定する必要があります。

検証

サンプル httpbin サービスと sleep アプリを使用して、イングレスゲートウェイからの mTLS トラフィックをチェックし、cert-manager ツールがインストールされていることを確認します。

  1. 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
  2. sleephttpbin サービスにアクセスできることを確認します。

    $ 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

  3. Ingress ゲートウェイから httpbin サービスへの mTLS トラフィックを確認します。

    $ oc apply -n <namespace> -f https://raw.githubusercontent.com/maistra/istio/maistra-2.4/samples/httpbin/httpbin-gateway.yaml
  4. istio-ingressgateway ルートを取得します。

    INGRESS_HOST=$(oc -n istio-system get routes istio-ingressgateway -o jsonpath='{.spec.host}')
  5. Ingress ゲートウェイから httpbin サービスへの mTLS トラフィックを確認します。

    $ curl -s -I http://$INGRESS_HOST/headers -o /dev/null -w "%{http_code}" -s

2.13.7. 関連情報

OpenShift Container Platform の cert-manager Operator のインストール方法は、Red Hat OpenShift の cert-manager Operator のインストール を参照してください。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.