7.2. Image Mode for RHEL でのシークレットの注入
Image Mode for RHEL には、シークレットに関する独自のメカニズムがありません。いくつかのケースでは、以下のようにコンテナープルシークレットをシステムに注入できます。
bootcが認証の必要なレジストリーから更新を取得するには、ファイルにプルシークレットを含める必要があります。次の例では、credsシークレットにレジストリープルシークレットが含まれています。FROM registry.redhat.io/rhel9/bootc-image-builder:latest COPY containers-auth.conf /usr/lib/tmpfiles.d/link-podman-credentials.conf RUN --mount=type=secret,id=creds,required=true cp /run/secrets/creds /usr/lib/container-auth.json && \ chmod 0600 /usr/lib/container-auth.json && \ ln -sr /usr/lib/container-auth.json /etc/ostree/auth.jsonビルドするには、
podman build --secret id=creds,src=$HOME/.docker/config.jsonを実行します。コンテナーイメージに埋め込まれた共通の永続ファイル (例:/usr/lib/container-auth.json) へのシンボリックリンクを両方の場所に対して使用することで、bootcと Podman に単一のプルシークレットを使用します。Podman がコンテナーイメージを取得するには、
/etc/containers/auth.jsonにプルシークレットを含めます。この設定では、2 つのスタックが/usr/lib/container-auth.jsonファイルを共有します。- コンテナービルドにシークレットを埋め込むことによるシークレットの注入
- レジストリーサーバーが適切に保護されている場合は、コンテナーイメージにシークレットを含めることができます。場合により、ブートストラップシークレットのみをコンテナーイメージに埋め込むことが実行可能なパターンになることがあります。特に、マシンをクラスターに対して認証するメカニズムと併用した場合が該当します。このパターンでは、プロビジョニングツールは、ホストシステムの一部として実行されるか、コンテナーイメージの一部として実行されるかに関係なく、ブートストラップシークレットを使用して SSH キーや証明書などの他のシークレットを注入または更新します。
- クラウドメタデータを使用したシークレットの注入
-
実稼働環境の Infrastructure as a Service (IaaS) システムのほとんどは、シークレット (特にブートストラップシークレット) をセキュアにホストできる、メタデータサーバーまたは同等のものをサポートします。コンテナーイメージには、これらのシークレットを取得するための
cloud-initやignitionなどのツールを含めることができます。 - ディスクイメージにシークレットを埋め込むことによるシークレットの注入
-
bootstrap secretsは、ディスクイメージにのみ埋め込むことができます。たとえば、AMI や OpenStack などの入力コンテナーイメージからクラウドディスクイメージを生成する場合、ディスクイメージには、実質的にマシンローカル状態であるシークレットが含まれることがあります。これらをローテーションするには、追加の管理ツールを使用するか、ディスクイメージを更新する必要があります。 - ベアメタルインストーラーを使用したシークレットの注入
- インストーラーツールは通常、シークレットを使用した設定の注入をサポートします。
systemd認証情報を使用したシークレットの注入-
systemdプロジェクトには、認証情報のデータをセキュアに取得してシステムやサービスに渡すための認証情報の概念があります。これは、一部のデプロイメント方法に適用されます。詳細は、systemd credentials のドキュメントを参照してください。
関連情報
- Example bootable containers を参照してください。
