手動でサービス認証情報をクラスタにバインドする

始める前に

• 以下の役割があることを確認してください。
  • エディター または 管理者 IBM Cloud IAMプラットフォームアクセスロール サービスをバインドしたいクラスタの
  • ライター または マネージャー IBM Cloud IAM サービスアクセスロール サービスをバインドしたい Kubernetes ネームスペースのためのものです。
• アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。

以下の手順を実行することで、クラスタにサービス資格情報を手動で追加できます。

1. クラスタに追加したいサービスのインスタンス名を取得します。

   ibmcloud resource service-instances
   

2. サービス・キーを作成します。 詳しくは コマンド・リファレンスを 参照のこと。

   ibmcloud resource service-key-create NAME [ROLE] --instance-name SERVICE_INSTANCE
   

3. Credentials の部分をコピーして、 creds という拡張子のないファイルに保存します。

4. 作成した認証情報ファイルを使用して、 Kubernetes の秘密鍵を作成します。

   kubectl create secret generic my-secret --from-file=path/to/creds
   

service bind CLIを使用したクラスタへのサービスの追加

バインディング時に既存のサービス認証情報を使用できますか？

オプションで、 service bind コマンドを実行するときに --key パラメータを指定し、既存のサービス資格情報の名前を指定することができます。 IBM Cloud サービスバインディングは、既存のサービス資格情報を使用して Kubernetes シークレットを自動的に作成します。

既存のクレデンシャルがワンタイム・ビューのクレデンシャルである場合はどうなりますか？

service bind コマンドは、独自のワンタイム・ビュー認証情報の持ち込みをサポートしていない。 したがって、 service bind コマンドを使用したい場合は、 --key パラメータを指定しないでください。 --key を指定せずにコマンドを実行すると、新しい認証情報のセットが作成される。

ワンタイム・ビューの認証情報を使用する場合は、サービスを クラスタに手動で バインドする必要があります。 このオプションでは、既存のワンタイムビュー認証情報を使用できます。

プライベート・クラウド・サービス・エンドポイントを使用するサービス資格情報を使用する場合はどうすればよいですか?

デフォルトでは、 service bind コマンドはパブリック・クラウド・サービス・エンドポイントにサービス・クレデンシャルを作成する。 プライベート・クラウド・サービス・エンドポイントを使用するには、プライベート・クラウド・サービス・エンドポイントを使用するサービスのサービス資格情報を手動で作成してから、--key オプションを使用して既存のサービス資格情報の名前を指定する必要があります。 自分のクレデンシャルを持参する予定の場合は、既存のクレデンシャルがワンタイム・ビュー・クレデンシャルでないことを確認してください。 詳細については、 ワンタイム・クレデンシャルを 参照のこと。

使用しているサービスが、まだプライベート・クラウド・サービス・エンドポイントをサポートしていない可能性もあります。 プライベート専用クラスターがある場合は、プライベート・クラウド・サービス・エンドポイントを使用するサービス資格情報を使用するか、パブリック IP アドレスとポートを開いてサービスに接続する必要があります。

サービス資格情報をクラスタにバインドする手順については、以下のセクションを参照してください。

IBM Cloud サービス・バインディングを使用して、ご使用の IBM Cloud サービスのサービス資格情報を自動的に作成して、これらの資格情報を Kubernetes シークレットに保管します。

サービスがプライベート・クラウド・サービス・エンドポイントをサポートしている場合、プライベート・クラウド・サービス・エンドポイントを使用してサービス・クレデンシャルを手動で作成し、 --key オプションを使用してクレデンシャルの名前を指定できます。

始める前に

• 以下の役割があることを確認してください。
  • エディター または 管理者 IBM Cloud IAMプラットフォームアクセスロール サービスをバインドしたいクラスタの
  • ライター または マネージャー IBM Cloud IAM サービスアクセスロール サービスをバインドしたい Kubernetes ネームスペースのためのものです。
• アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。

クラスターに IBM Cloud サービスを追加するには、以下の手順を実行します。

1. IBM Cloud サービスのインスタンスを作成します。

   • 一部の IBM Cloud サービスは、選択されたリージョンでのみ使用可能です。 サービスがクラスターと同じリージョンで使用可能な場合にのみ、サービスをクラスターにバインドできます。 さらに、ワシントン DC ゾーンでサービス・インスタンスを作成する場合は、CLI を使用する必要があります。
   • IAM 対応サービスの場合: クラスターと同じリソース・グループ内にサービス・インスタンスを作成する必要があります。 サービスは 1 つのリソース・グループ内にしか作成できず、作成後にそのリソース・グループを変更することはできません。
   • サービス名の形式が myservice または example.com であることを確認してください。 スペースとアンダースコアは使用できません。

2. 作成したサービスのタイプを確認し、サービス・インスタンスの名前をメモします。

   ibmcloud resource service-instances
   

   出力例

   NAME                          Location   State    Type               Tags
   <iam_service_instance_name>   <region>   active   service_instance
   

3. サービスを追加するために使用するクラスターの名前空間を識別します。

   kubectl get namespaces
   

4. サービスをクラスターにバインドして、パブリック・クラウド・サービス・エンドポイントを使用するサービスのサービス資格情報を作成して、それらの資格情報を Kubernetes シークレットに保管します。 既存のサービス・クレデンシャルがある場合は、 --key オプションを使用してクレデンシャルの名前を指定します。 IAM 対応サービスの場合、資格情報は Writer サービス・アクセス・ロールで自動的に作成されますが、 --role オプションを使用して別のサービス・アクセス・ロールを指定できます。 --key オプションを使用する場合は、 --role オプションを含めないでください。

   独自のクレデンシャルを持参する予定の場合は、既存のクレデンシャルがワンタイム・ビュー・クレデンシャルでないことを確認するか、クラスタにサービス・クレデンシャルを手動で保存する推奨方法を使用してください。 詳細については、 ワンタイム・クレデンシャルを 参照のこと。

   ibmcloud ks cluster service bind --cluster <cluster_name_or_ID> --namespace <namespace> --service <service_instance_name> [--key <service_instance_key>] [--role <IAM_service_role>]
   

   サービス資格情報が正常に作成されると、binding-<service_instance_name> という名前の Kubernetes シークレットが作成されます。

   出力例

   ibmcloud ks cluster service bind --cluster mycluster --namespace mynamespace --service cleardb
   Binding service instance to namespace...
   OK
   Namespace:         mynamespace
   Secret name:     binding-<service_instance_name>
   

5. Kubernetes シークレットでサービス資格情報を確認します。

   1. シークレットの詳細を取得し、binding 値をメモします。 binding 値は base64 エンコードであり、サービス・インスタンスの資格情報を JSON 形式で保持します。

      kubectl get secrets binding-<service_instance_name> --namespace=<namespace> -o yaml
      

      出力例

      apiVersion: v1
      data:
      binding: <binding>
      kind: Secret
      metadata:
        annotations:
          service-instance-id: 1111aaaa-a1aa-1aa1-1a11-111aa111aa11
          service-key-id: 2b22bb2b-222b-2bb2-2b22-b22222bb2222
        creationTimestamp: 2018-08-07T20:47:14Z
        name: binding-<service_instance_name>
        namespace: <namespace>
        resourceVersion: "6145900"
        selfLink: /api/v1/namespaces/default/secrets/binding-mycloudant
        uid: 33333c33-3c33-33c3-cc33-cc33333333c
      type: Opaque
      

   2. バインディング値をデコードします。

      echo "<binding>" | base64 -D
      

      出力例

      {"apikey":"<API_key>","host":"<ID_string>-bluemix.cloudant.com","iam_apikey_description":"Auto generated apikey during resource-key operation for Instance - crn:v1:bluemix:public:cloudantnosqldb:us-south:a/<ID_string>::","iam_apikey_name":"auto-generated-apikey-<ID_string>","iam_role_crn":"crn:v1:bluemix:public:iam::::serviceRole:Writer","iam_serviceid_crn":"crn:v1:bluemix:public:iam-identity::a/1234567890brasge5htn2ec098::serviceid:ServiceId-<ID_string>","password":"<ID_string>","port":443,"url":"https://<ID_string>-bluemix.cloudant.com","username":"123b45da-9ce1-4c24-ab12-rinwnwub1294-bluemix"}
      

   3. オプション: 前のステップでデコードしたサービス資格情報を、IBM Cloud ダッシュボードのサービス・インスタンスで検索したサービス資格情報と比較します。

6. これでサービスがクラスターにバインドされたため、Kubernetes シークレットのサービス資格情報にアクセスするために、アプリを構成する必要があります。

アプリからのサービス資格情報へのアクセス

アプリから IBM Cloud サービス・インスタンスにアクセスするには、Kubernetes シークレットに保管されているサービス資格情報をアプリで使用可能にする必要があります。

サービス・インスタンスの資格情報は base64 エンコードであり、JSON 形式でシークレットの内部に保管されます。 シークレットにあるデータにアクセスするには、次のオプションの中から選択します。

• Secret をボリュームとしてポッドにマウントする
• 環境変数で Secret を参照する

始める前に

• kube-system ネームスペースの Writer または Manager IBM Cloud IAM サービス・アクセス・ロールが あることを確認します。
• アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。
• IBM Cloud サービスをクラスターに追加します。

クラスターからのサービスの削除

クラスターにバインドした IBM Cloud サービスを使用しない場合は、クラスターから Kubernetes シークレットと、シークレットにアクセスするポッドを手動で削除できます。

1. クラスターにバインドされているサービスをリストし、サービスの名前と、サービスがバインドされている名前空間をメモします。

   ibmcloud ks cluster service ls --cluster
   

   出力例

   OK
   Service   Instance GUID                          Key                                                                  Namespace   
   myservice 12345ab1-1234-1abc-a12b-12abc12a12ab   kube-a1a12abcd12a123abc1a12ab1a1234ab7.abcdefg0p1abcd123lgg.default   default  
   

2. サービスがバインドされている名前空間内の Kubernetes シークレットをリストし、形式 binding-<service_name> に従う名前のシークレットを探します。

   kubectl get secrets -n <namespace> | grep Opaque
   

   出力例

   binding-myservice   Opaque     1      3d23h
   

3. シークレットにアクセスするすべてのポッドを取得します。

   kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.volumes[*]}{.secret.secretName}{" "}{end}{end}' | grep "<secret_name>"
   

   CLI 出力が空の場合は、このシークレットをマウントしたポッドがクラスターに存在しません。

4. シークレットをマウントしたポッドがある場合は、ポッドまたはポッドを管理するデプロイメントを削除するか、代わりに別のシークレットを使用するようにポッド YAML およびデプロイメント YAML を更新します。

   • ポッドまたはデプロイメントを削除するには、以下のようにします。

     kubectl delete pod <pod_name> -n <namespace>
     

     kubectl delete deployment <deployment_name> -n <namespace>
     

   • 既存のポッドまたはデプロイメントを更新するには、以下のようにします。
     1. ポッド YAML ファイルまたはデプロイメント YAML ファイルを取得します。

        kubectl get pod <pod_name> -o yaml
        

        kubectl get deployment <deployment_name> -o yaml
        

     2. YAML ファイルをコピーし、spec.volumes セクションで、使用するシークレットの名前を変更します。
     3. 変更をクラスターに適用します。

        kubectl apply -f pod.yaml
        

        kubectl apply -f deployment.yaml
        

     4. 更新したボリューム仕様の新しいポッドが作成されていることを確認します。

        kubectl get pods
        

        kubectl describe pod <pod_name>
        

5. そのシークレットを削除します。

   kubectl delete secret <secret_name> -n <namespace>
   

6. シークレットが削除されたことを確認します。

   kubectl get secrets -n <namespace>
   

7. オプション。 IBM Cloud サービス・インスタンスを削除します。

   ibmcloud resource service-instance-delete <service_name>