IBM-提供されたIngressサブドメインに TLS シークレットを設定する

IBM はIngressサブドメインとデフォルトの TLS 証明書を提供し、Ingressリソースで指定できる Kubernetes シークレットとしてクラスタに保存されます。 IBM 提供の TLS 証明書は、LetsEncrypt によって署名され、IBM によって完全に管理されます。

IBM 提供の Ingress サブドメイン・ワイルドカード *.<cluster_name>-<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud は、デフォルトでクラスターに登録されています。 IBM 提供の TLS 証明書はワイルドカード証明書ですので、ワイルドカード・サブドメインに使用できます。

IBM-提供されたIngressサブドメインにデフォルトの TLS 証明書を使用する手順に従ってください。

1. デフォルトの TLS 証明書が保存されている秘密の名前を取得します。 これは、Ingress リソースの spec.tls セクションで指定するシークレット名であることに注意してください。

   ibmcloud oc cluster get -c CLUSTER | grep Ingress
   

   出力例

   Ingress Subdomain:      mycluster-<hash>-0000.us-south.containers.appdomain.cloud
   Ingress Secret:         mycluster-<hash>-0000
   

2. シークレットの詳細を表示し、CRN 値をメモします。 これは、 TLS 証明書のCRNである。 デフォルトの [Secrets Manager] クラスタにデフォルト・インスタンスが登録されていない場合、シークレットにはCRNがありません。 詳しくは、以下のステップの注を参照してください。

   ibmcloud oc ingress secret get -c CLUSTER --name SECRET_NAME --namespace openshift-ingress
   

3. Ingressリソースやアプリが存在する各ネームスペースで、デフォルトの TLS 証明書のシークレットを作成します。 --cert-crn コマンド・オプションで TLS 証明書の CRN を指定する。

   ibmcloud oc ingress secret create --cluster CLUSTER_NAME_OR_ID --cert-crn CRN --name SECRET_NAME --namespace openshift-ingress
   

   秘密鍵をコピーするには、デフォルトの Secrets Manager インスタンスがクラスター ibmcloud oc ingress secret create に登録されている必要があります。 Secrets Manager インスタンスがなく、シークレットが代わりにクラスターに直接書き込まれている場合、シークレットには必要なCRN値が設定されていません。そのため、 OpenShiftocプラグインコマンドを使用して手動でコピーする必要があります。

カスタムサブドメインの TLS シークレットの設定

Ingress リソースにカスタム・サブドメインを定義する場合は、独自の TLS 証明書を使用して TLS 終端を管理できます。 TLS 証明書を保存するために Kubernetes シークレットを作成し、アプリが存在する各ネームスペースにこのシークレットをインポートする必要があります。

カスタム TLS 証明書を Secrets Manager に格納することで、証明書をクラスタの Kubernetes シークレットに直接インポートすることができます。

1. Ingress リソースが存在するネームスペースで、 TLS 証明書のシークレットを作成またはインポートします。 例えば、以下のコマンドを実行することで、 Secrets Manager からクラスターにシークレットをインポートできます。 --cert-crn コマンド・オプションで、 TLS 証明書の CRN を指定する。

   証明書をコマンド ibmcloud oc ingress secret create でインポートするには、クラスターにデフォルトの Secrets Manager インスタンスが登録されている必要があります。 Secrets Manager インスタンスがなく、シークレットが代わりにクラスターに直接書き込まれている場合、シークレットには必要なCRN値が設定されていません。そのため、 OpenShiftocプラグインコマンドを使用して手動でコピーする必要があります。

   ibmcloud oc ingress secret create --name SECRET_NAME --cluster CLUSTER_NAME_OR_ID --cert-crn CERTIFICATE_CRN --namespace openshift-ingress
   

2. アプリが存在する名前空間ごとに前のステップを繰り返します。

クラスタ内で TLS 以外のシークレットを作成する

コマンドに --type Opaque オプションを指定して、 TLS 以外のシークレットを作成する。 ibmcloud oc ingress secret create コマンドで指定する。 Opaque タイプでは、複数の非証明書 CRN 値を含めることができます。 --type オプションが指定されていない場合、デフォルトで TLS が適用されます。 詳細および追加のコマンド・オプションについては、 CLI リファレンス を参照してください。

以下のコマンド例では、 Opaque タイプを指定して、 TLS 以外のシークレットを作成している。 TLS 以外の秘密は、少なくとも1つの秘密 フィールドを 必要とする。 --field オプションの指定方法は、 作成するシークレットのタイプによって 異なることに注意してください。

ibmcloud oc ingress secret create -c cluster-test --name example-secret --namespace openshift-ingress --field crn:v1:bluemix:public:secrets-manager:us-south:a/1aa111aa1a11111aaa1a1111aa1aa111:111a1111-11a1 --type Opaque

シークレットが作成されたことを確認するには、名前空間内のすべてのシークレットをリストします。

kubectl get secret -n default

以下の例は、その出力を示しています。

NAME                   TYPE                                  DATA   AGE
all-icr-io             kubernetes.io/dockerconfigjson        1      41h
default-token-8t6xw    kubernetes.io/service-account-token   3      41h
example-secret         Opaque                                        3m

TLS 以外のシークレットフィールドの管理

シークレットフィールドは、 TLS でないシークレットに格納されるキーと値のペアである。 以下の例を参照して、 TLS 以外のシークレットフィールドを表示、追加、更新、または削除してください。

kubectl get secret -n default example-secret -o yaml

apiVersion: v1
data:
  arbitraryFVT: AAAaaAAaAAA1AAAaaAAa
  userCredsFVT_password: aAAaa1aaaA=
  userCredsFVT_username: aAAaaa==
kind: Secret
metadata:
  annotations:
    ingress.cloud.ibm.com/cert-source: ibm
    razee.io/build-url: https://url.com
    razee.io/source-url: https://url.com
  creationTimestamp: "2022-11-08T19:45:05Z"
  name: example-secret
  namespace: default
  resourceVersion: "111111"
  uid: 1aaa1111-1a11-111a-a1a1-11111a1a1a1a
type: Opaque

ibmcloud oc ingress secret field add --cluster example-cluster --name example-iam-secret --namespace openshift-ingress  --field crn:v1:bluemix:public:secrets-manager:us-south:a/1aa111aa-1a11-111a-aa1a-1111aa1aa111:secret:111a1111-11a1-11aa-a1a1-111aa12345aa --field custom_iam_name=crn:v1:bluemix:public:secrets-manager:us-south:a/1aa111aa-1a11-111a-aa1a-1111aa1aa111:secret:111a1111-11a1-11aa-a1a1-111aa12345aa --field prefix=crn:v1:bluemix:public:secrets-manager:us-south:a/1aa111aa-1a11-111a-aa1a-1111aa1aa111:secret:111a1111-11a1-11aa-a1a1-111aa12345aa

data:
  api_key: bmZrUHR1VS1fNVpMOExsTmIxeTdQcXFTSENMc2pTUjRsNTQyTzZkZ2ZQMkk=  # Default field type using the default `api_key` field name
  custom_iam_name: bmZrUHR1VS1fNVpMOExsTmIxeTdQcXFTSENMc2pTUjRsNTQyTzZkZ2ZQMkk=  # Named field type using the specified `custom_iam_name` field name.
  iam_api_key: bmZrUHR1VS1fNVpMOExsTmIxeTdQcXFTSENMc2pTUjRsNTQyTzZkZ2ZQMkk= # Prefixed field type using the `iam` name in Secrets Manager followed by the `api_key` default name.

ibmcloud oc ingress secret update --cluster example-cluster --name example-secret --namespace openshift-ingress

ibmcloud oc ingress secret field rm -c example-cluster --name example-secret --namespace openshift-ingress --field-name example-Field

kubectl get secret -n default example-secret -o yaml