ケーススタディ: クラウドシークレットの管理

streaming-ops プロジェクト は本稼働環境のシミュレーションであり、Confluent Cloud 上の Apache Kafka® をターゲットとする、ストリーミングマイクロサービスをベースにしたアプリケーションを実行しています。アプリケーションとリソースは、宣言型インフラストラクチャである Kubernetes および オペレーターパターン を使用して GitOps によって管理されます。

このケーススタディでは、Kubernetes クラスター内の自動化システムを実現するために、Confluent Cloud へのアクセスに使用するシークレットを管理する方法を検討します。

宣言型シークレット

Kubernetes は、アプリケーションのデプロイ、構成、およびその他の関連メタデータを管理するための宣言型 API を提供します。API には、Secret タイプが含まれており、これを使用してパスワード、SSH キー、またはその他のシークレットデータなどの機密情報を保管し、管理することができます。

注釈

タイプ Secret の Kubernetes オブジェクトでは、機密データが完全には保護されません。Secret 内に格納されたデータは暗号化されていないため、そのオブジェクトへの読み取りアクセス許可を持つすべての Kubernetes ユーザーが表示できます。Secret オブジェクトをセキュリティで保護し、認可されていないアクセスを防ぐには、Kubernetes の ロールベースアクセス制御(RBAC) を使用します。

分散システムでの機密データの管理に使用できるソリューションは複数存在しますが、streaming-ops プロジェクトでは、Bitnami Sealed Secrets という、Kubernetes ネイティブのオープンソースソリューションを使用します。Sealed Secrets を使用すると、他のすべての Kubernetes オブジェクトに使用されるものと同じ GitOps と宣言型アプローチを使用してシークレットを管理することができます。このケーススタディでは、Kubernetes クラスター内で自動化スクリプトで使用するために、streaming-ops が Sealed Secrets をどのように使用して、宣言ベースの GitOps アプローチにより Confluent Cloud CLI の認証情報を保管するかを示します。

Sealed Secrets コントローラー

Sealed Secrets ソリューションのメインコンポーネントは SealedSecret コントローラー です。このコントローラーは Kubernetes クラスター内にデプロイされ、シークレットの暗号化用のキーを提供し、SealedSecret タイプへの変更を検出するために Kubernetes API をモニタリングします。また、復号化された Secret オブジェクトを Kubernetes API にデプロイして、アプリケーションが使用できるようにします。

streaming-ops は kubectl と、Sealed Secret プロジェクトが提供する デプロイマニフェスト を使用して、コントローラーをデプロイします。

kubectl apply -f https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.12.4/controller.yaml

詳細については、プロジェクトの Makefile を参照してください。

シークレットのシーリング

シークレットのシーリングの最初の手順は、シーリングするローカル Secret ファイルを作成することです。これを行うために streaming-ops は、まず、キー/値ペアの環境ファイルにシークレット値を保管します。ccloud CLI は、自動ログインに使用できる環境変数を探します。これで、次のプロパティファイルを適切な値で使用できます。

CCLOUD_EMAIL=emailaddress@email.com
CCLOUD_PASSWORD=YYYYYYYYYY

次に、標準 kubectl create secret コマンドを --dry-run=client オプションを指定して実行し、ローカル Secret ファイルを作成します。

# Ensure usage of ``--dry-run=client`` to ensure creation of local file only
kubectl create secret generic secret-name --namespace=default --from-env-file=ccloud-secrets.props --dry-run=client -o yaml > ccloud-secrets-to-seal.yaml

前の手順で作成した Secret ファイルには、入力プロパティファイルと同じ機密データが含まれるため、両方のファイルを、通常の機密データを保護する場合と同じ方法で保護します。

これで、次のように Bitnami Sealed Secrets kubeseal コマンドを使用して SealedSecret ファイルを作成することができます。

kubeseal < ccloud-secrets-to-seal.yaml > ccloud-secrets-sealed.yaml

作成された ccloud-secrets-sealed.yaml ファイルは暗号化されており、これを復号化できるのは、Kubernetes クラスター内の SealedSecret コントローラーのみです。これにより、このファイルは、プライベートまたはパブリックの Git リポジトリに安全にコミットできます。

GitOps によるシークレットのデプロイ

SealedSecret プロセスを使用してファイルをシーリングした後は、既存の GitOps プロセスを使用して、これらのシークレットが自動ツールで消費されるように、Kubernetes クラスターにデプロイすることができます。プロセスがモニタリングするフォルダーに SealedSecret ファイルをコミットすると、このファイルが Kubernetes API にデプロイされます。GitHub <https://github.com/confluentinc/kafka-devops/tree/master/secrets/sealed/dev>__Flux GitOps コントローラー によりモニタリングされるフォルダー) には、dev 環境用の streaming-ops の SealedSecret ファイルがあります。Flux はデプロイされると、secrets/sealed フォルダーをモニタリングして変更を検出するように構成されます。詳細については、flux-init.sh スクリプト を参照してください。

Flux によって SealedSecret オブジェクトがデプロイされたら、Kubernetes API 内で SealedSecrets コントローラーによって認識され、値が復号化されて、同等の Secret オブジェクトが Kubernetes API にポストされます。その後、これらの Secret オブジェクトを、環境変数またはボリュームマウントファイルのように、Kubernetes 内のワークロードが標準 Kubernetes 方式で使用 することができます。

streaming-ops での Sealed Secrets の使用方法の詳細については、GitHub リポジトリ Makefile および 各スクリプト を参照してください。

streaming-ops の動作例

この詳細および他の運用ユースケースについては、Kubernetes と GitOps を使用する Apache Kafka® 用 DevOps の詳細なドキュメントとプロジェクトの GitHub リポジトリ を参照してください。