IBM提供の Ingress サブドメイン用の TLS シークレットのセットアップ

IBM は、Ingress サブドメインと、クラスター内に Kubernetes シークレットとして保管されているデフォルトの TLS 証明書を提供します。これらは、Ingress リソースで指定できます。 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 ks 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 ks ingress secret get -c <cluster> --name <secret_name> --namespace default
   

3. Ingress リソースまたはアプリが存在する各名前空間に、デフォルトの TLS 証明書のシークレットを作成します。 --cert-crn コマンド・オプションを使用して TLS 証明書 CRN を指定します。

   あるいは、defaultCertificate 構成マップibm-ingress-deploy-configでシークレットを として設定することもできます。

   ibmcloud ks ingress secret create --cluster <cluster_name_or_ID> --cert-crn <CRN> --name <secret_name> --namespace default
   

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

カスタム・サブドメインの TLS シークレットのセットアップ

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

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

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

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

   ibmcloud ks ingress secret create --name <secret_name> --cluster <cluster_name_or_ID> --cert-crn <certificate_crn> --namespace default
   

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

クラスターでの非 TLS シークレットの作成

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

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

ibmcloud ks ingress secret create -c cluster-test --name example-secret --namespace default --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://travis.ibm.com/alchemy-containers/armada-ingress-secret-mgr/builds/78876583
    razee.io/source-url: https://github.ibm.com/alchemy-containers/armada-ingress-secret-mgr/commit/651fa822632128163cf638c47f0a14b1e0e2915a
  creationTimestamp: "2022-11-08T19:45:05Z"
  name: example-secret
  namespace: default
  resourceVersion: "111111"
  uid: 1aaa1111-1a11-111a-a1a1-11111a1a1a1a
type: Opaque

ibmcloud ks ingress secret field add --cluster example-cluster --name example-iam-secret --namespace default  --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 ks ingress secret update --cluster example-cluster --name example-secret --namespace default

ibmcloud ks ingress secret field rm -c example-cluster --name example-secret --namespace default --field-name example-Field

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