第10章 セキュリティー

手順

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

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

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

手順

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

   $ export san="knative"

   Copy to Clipboard Toggle word wrap
   注記

   これらの証明書が <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

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

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 -

      Copy to Clipboard Toggle word wrap

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

      KnativeServing CR の例

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

      Copy to Clipboard Toggle word wrap

手順

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

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

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

   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>

   Copy to Clipboard Toggle word wrap

検証

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

   $ oc get domainmapping <domain_name>

   Copy to Clipboard Toggle word wrap

   出力例

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

   Copy to Clipboard Toggle word wrap

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

   $ curl https://<domain_name>

   Copy to Clipboard Toggle word wrap

   証明書が自己署名されている場合は、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

   Copy to Clipboard Toggle word wrap
   重要

   キー名に 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>
   ...

   Copy to Clipboard Toggle word wrap

手順

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

   Copy to Clipboard Toggle word wrap
   重要

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

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

   $ oc edit knativekafka

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap
   注記

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

   以下に例を示します。

   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

   Copy to Clipboard Toggle word wrap