第10章 セキュリティー

手順

1. 仕様に internal-encryption: "true" フィールドを含む Knative サービスを作成します。

   ...
   spec:
     config:
       network:
         internal-encryption: "true"
   ...

2. knative-serving namespace でアクティベーター Pod を再起動して、証明書を読み込みます。

   $ oc delete pod -n knative-serving --selector app=activator

手順

1. サーバー証明書を knative-serving-ingress namespace にデプロイします。

   $ export san="knative"

   注記

   これらの証明書が <app_name>.<namespace>.svc.cluster.local への要求を処理できるように、Subject Alternative Name (SAN) の検証が必要です。

2. ルートキーと証明書を生成します。

   $ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 \
       -subj '/O=Example/CN=Example' \
       -keyout ca.key \
       -out ca.crt

3. SAN 検証を使用するサーバーキーを生成します。

   $ openssl req -out tls.csr -newkey rsa:2048 -nodes -keyout tls.key \
     -subj "/CN=Example/O=Example" \
     -addext "subjectAltName = DNS:$san"

4. サーバー証明書を作成します。

   $ openssl x509 -req -extfile <(printf "subjectAltName=DNS:$san") \
     -days 365 -in tls.csr \
     -CA ca.crt -CAkey ca.key -CAcreateserial -out tls.crt

5. Courier ローカルゲートウェイのシークレットを設定します。

   1. 前の手順で作成した証明書から、knative-serving-ingress namespace にシークレットをデプロイします。

      $ oc create -n knative-serving-ingress secret tls server-certs \
          --key=tls.key \
          --cert=tls.crt --dry-run=client -o yaml | oc apply -f -

   2. KnativeServing カスタムリソース (CR) 仕様を更新して、Kourier ゲートウェイによって作成されたシークレットを使用します。

      KnativeServing CR の例

      ...
      spec:
        config:
          kourier:
            cluster-cert-secret: server-certs
      ...

手順

1. Kubernetes TLS シークレットを作成します。

   $ oc create secret tls <tls_secret_name> --cert=<path_to_certificate_file> --key=<path_to_key_file>

2. Red Hat OpenShift Service Mesh を OpenShift Serverless インストールのイングレスとして使用している場合は、Kubernetes TLS シークレットに次のラベルを付けます。

   “networking.internal.knative.dev/certificate-uid": “<value>”

   cert-manager などのサードパーティーのシークレットプロバイダーを使用している場合は、Kubernetes TLS シークレットに自動的にラベルを付けるようにシークレットマネージャーを設定できます。Cert-manager ユーザーは、提供されたシークレットテンプレートを使用して、正しいラベルを持つシークレットを自動的に生成できます。この場合、シークレットのフィルターリングはキーのみに基づいて行われますが、この値には、シークレットに含まれる証明書 ID などの有用な情報が含まれている可能性があります。

   注記

   {cert-manager-operator} はテクノロジープレビュー機能です。詳細は、{cert-manager-operator} のインストール に関するドキュメントを参照してください。

3. 作成した TLS シークレットを使用するように DomainMapping CR を更新します。

   apiVersion: serving.knative.dev/v1alpha1
   kind: DomainMapping
   metadata:
     name: <domain_name>
     namespace: <namespace>
   spec:
     ref:
       name: <service_name>
       kind: Service
       apiVersion: serving.knative.dev/v1
   # TLS block specifies the secret to be used
     tls:
       secretName: <tls_secret_name>

検証

1. DomainMapping CR のステータスが True であることを確認し、出力の URL 列に、マップされたドメインをスキームの https で表示していることを確認します。

   $ oc get domainmapping <domain_name>

   出力例

   NAME                      URL                               READY   REASON
   example.com               https://example.com               True

2. オプション: サービスが公開されている場合は、以下のコマンドを実行してこれが利用可能であることを確認します。

   $ curl https://<domain_name>

   証明書が自己署名されている場合は、curl コマンドに -k フラグを追加して検証を省略します。

手順

1. 証明書ファイルを knative-eventing namespace にシークレットファイルとして作成します。

   $ oc create secret -n knative-eventing generic <secret_name> \
     --from-literal=protocol=SSL \
     --from-file=ca.crt=caroot.pem \
     --from-file=user.crt=certificate.pem \
     --from-file=user.key=key.pem

   重要

   キー名に ca.crt、 user.crt、および user.key を使用します。これらの値は変更しないでください。

2. KnativeKafka CR を編集し、broker 仕様にシークレットへの参照を追加します。

   apiVersion: operator.serverless.openshift.io/v1alpha1
   kind: KnativeKafka
   metadata:
     namespace: knative-eventing
     name: knative-kafka
   spec:
     broker:
       enabled: true
       defaultConfig:
         authSecretName: <secret_name>
   ...

手順

1. 選択された namespace にシークレットとして証明書ファイルを作成します。

   $ oc create secret -n <namespace> generic <kafka_auth_secret> \
     --from-file=ca.crt=caroot.pem \
     --from-file=user.crt=certificate.pem \
     --from-file=user.key=key.pem

   重要

   キー名に ca.crt、 user.crt、および user.key を使用します。これらの値は変更しないでください。

2. KnativeKafka カスタムリソースの編集を開始します。

   $ oc edit knativekafka

3. シークレットおよびシークレットの namespace を参照します。

   apiVersion: operator.serverless.openshift.io/v1alpha1
   kind: KnativeKafka
   metadata:
     namespace: knative-eventing
     name: knative-kafka
   spec:
     channel:
       authSecretName: <kafka_auth_secret>
       authSecretNamespace: <kafka_auth_secret_namespace>
       bootstrapServers: <bootstrap_servers>
       enabled: true
     source:
       enabled: true

   注記

   ブートストラップサーバーで一致するポートを指定するようにしてください。

   以下に例を示します。

   apiVersion: operator.serverless.openshift.io/v1alpha1
   kind: KnativeKafka
   metadata:
     namespace: knative-eventing
     name: knative-kafka
   spec:
     channel:
       authSecretName: tls-user
       authSecretNamespace: kafka
       bootstrapServers: eventing-kafka-bootstrap.kafka.svc:9094
       enabled: true
     source:
       enabled: true