3.3.2. サービス証明書の追加

サービスとの通信のセキュリティーを保護するには、サービスと同じ namespace のシークレットに署名済みの提供証明書とキーのペアを生成します。

生成される証明書は、内部サービス DNS 名 <service.name>.<service.namespace>.svc にのみ有効であり、内部通信用にのみ有効です。サービスがヘッドレスサービス(clusterIP 値が設定されていない) である場合、生成された証明書には *.<service.name>.<service.namespace>.svc 形式のワイルドカードのサブジェクトも含まれます。

重要

生成された証明書にはヘッドレスサービスのワイルドカードサブジェクトが含まれるため、クライアントが個別の Pod を区別する必要がある場合はサービス CA を使用しないでください。この場合は、以下のようになります。

  • 別の CA を使用して個別の TLS 証明書を生成します。
  • サービス CA は、個々の Pod に送信される接続についての信頼される CA として許可することはできず、他の Pod がこの権限を借用することはできません。これらの接続は、個別の TLS 証明書の生成に使用されている CA を信頼するように設定される必要があります。

前提条件:

  • サービスが定義されていること。

手順

  1. サービスに service.beta.openshift.io/serving-cert-secret-name のアノテーションを付けます。

    $ oc annotate service <service_name> \1
         service.beta.openshift.io/serving-cert-secret-name=<secret_name> 2
    1
    <service_name> を、セキュリティー保護するサービスの名前に置き換えます。
    2
    <secret_name> は、証明書とキーのペアを含む生成されたシークレットの名前です。便宜上、これを <service_name> と同じにすることが推奨されます。

    たとえば、以下のコマンドを使用してサービス test1 にアノテーションを付けます。

    $ oc annotate service test1 service.beta.openshift.io/serving-cert-secret-name=test1
  2. アノテーションが存在することを確認するためにサービスを検査します。

    $ oc describe service <service_name>

    出力例

    ...
    Annotations:              service.beta.openshift.io/serving-cert-secret-name: <service_name>
                              service.beta.openshift.io/serving-cert-signed-by: openshift-service-serving-signer@1556850837
    ...

  3. クラスターがサービスのシークレットを生成した後に、Pod 仕様がこれをマウントでき、Pod はシークレットが利用可能になった後にこれを実行できます。

関連情報