第14章 Image Mode for RHEL でのユーザー、グループ、SSH 鍵、シークレットの管理
Image Mode for RHEL でのユーザー、グループ、SSH 鍵、およびシークレットの管理について詳しく説明します。
14.1. ユーザーとグループの設定 リンクのコピーリンクがクリップボードにコピーされました!
Image Mode for RHEL は、汎用的なオペレーティングシステムの更新および設定メカニズムです。次のリストで、選択したユースケースのベストプラクティスを参照してください。
- 汎用ベースイメージのユーザーとグループの設定
- 通常、ディストリビューションのベースイメージには設定がありません。セキュリティーリスクがあるため、汎用イメージ内の公開されている秘密鍵を使用してパスワードと SSH 鍵を暗号化しないでください。
systemd認証情報を使用した SSH 鍵の注入-
一部の環境では、
systemdを使用して、root パスワードまたは SSHauthorized_keysファイルを注入できます。たとえば、System Management BIOS (SMBIOS) を使用して、SSH 鍵システムファームウェアを注入します。これは、qemuなどのローカルな仮想化環境で設定できます。 cloud-initを使用したユーザーと SSH 鍵の注入-
多くの Infrastructure as a Service (IaaS) および仮想化システムは、
cloud-initやignitionなどのソフトウェアによって一般的に処理されるメタデータサーバーを使用します。AWS instance metadata を参照してください。cloud-initまたは Ignition は、使用しているベースイメージに含まれる場合があります。または、独自の派生イメージにインストールすることもできます。このモデルでは、SSH 設定は bootc イメージの外部で管理されます。 - コンテナーまたはユニットのカスタムロジックを使用したユーザーと認証情報の追加
-
cloud-initなどのシステムには特権がありません。コンテナーイメージを起動する方法で、認証情報を管理するための任意のロジックを注入できます。たとえば、systemdユニットを使用できます。認証情報を管理するには、FreeIPA などのカスタムのネットワークホストソースを使用できます。 - コンテナービルドでのユーザーと認証情報の静的な追加
パッケージ指向のシステムでは、次のコマンドにより、派生ビルドを使用してユーザーと認証情報を注入できます。
RUN useradd someuser
RUN useradd someuserCopy to Clipboard Copied! Toggle word wrap Toggle overflow shadow-utilsのデフォルトのuseradd実装に問題がある場合があります。ユーザーとグループの ID が動的に割り当てられることにより、ドリフトが発生する可能性があります。- ユーザーとグループのホームディレクトリーと
/varディレクトリー 永続的に
/homeに設定されたシステムの場合、最初のインストール後にコンテナーイメージで行われた/var/home /varへの変更は、その後の更新には適用されません。たとえば、コンテナービルドに
/var/home/someuser/.ssh/authorized_keysを注入した場合、既存のシステムは更新されたauthorized_keysファイルを取得しません。nss-altfilesの使用nss-altfilesは、システムユーザーを/usr/lib/passwdと/usr/lib/groupに分離します。この仕組みは、OSTree プロジェクトが/etc/passwdに関連する/etcの 3 方向マージを処理する方法と整合性を取るためのものです。現在、ローカルシステムで/etc/passwdファイルが何らかの方法で変更された場合、その後コンテナーイメージの/etc/passwdに対して行われた変更は適用されません。rpm-ostreeによってビルドされたベースイメージでは、nss-altfilesがデフォルトで有効になっています。また、ベースイメージには、UID または GID のドリフトを回避するために、NSS ファイルによって事前に割り当てられ、管理されるシステムユーザーがあります。
派生コンテナービルドでは、たとえば
/usr/lib/passwdにユーザーを追加することもできます。sysusers.dまたはDynamicUser=yesを使用します。systemdユニットでの DynamicUser=yes の使用システムユーザーの場合、可能な場合は
systemdDynamicUser=yesオプションを使用します。これは、潜在的な UID または GID のドリフトを回避できるため、パッケージのインストール時にユーザーまたはグループを割り当てるパターンよりもはるかに優れています。
systemd-sysusersの使用たとえば、派生ビルドでは
systemd-sysusers を使用します。詳細は、systemd-sysusers のドキュメントを参照してください。COPY mycustom-user.conf /usr/lib/sysusers.d
COPY mycustom-user.conf /usr/lib/sysusers.dCopy to Clipboard Copied! Toggle word wrap Toggle overflow sysusersツールは、必要に応じて起動時に従来の/etc/passwdファイルに変更を加えます。/etcが永続的であれば、UIDまたはGIDのドリフトを回避できます。つまり、UIDまたはGIDの割り当ては、特定のマシンがどのようにアップグレードされてきたかによって異なります。- ユーザーのマシンローカル状態
ファイルシステムのレイアウトは、ベースイメージによって異なります。
デフォルトでは、ユーザーデータはベースイメージに応じて、
/etc、/etc/passwd、/etc/shadowおよびgroupsと、/homeとの両方に保存されます。ただし、いずれの汎用ベースイメージもマシンローカルな永続状態である必要があります。このモデルでは、/homeは/var/home/userへのシンボリックリンクです。- システムプロビジョニング時のユーザーと SSH 鍵の注入
/etcと/varがデフォルトで永続化するように設定されたベースイメージの場合、Anaconda やキックスタートなどのインストーラーを使用してユーザーを注入できます。通常、汎用インストーラーは 1 回限りのブートストラップ用に設計されています。その後、設定はミュータブルなマシンローカル状態になり、他のメカニズムを使用して Day 2 操作で変更できるようになります。
Anaconda インストーラーを使用して初期パスワードを設定できます。ただし、この初期パスワードを変更するには、
passwdなどの別のシステム内ツールが必要です。これらのフローは
bootc-compatibleシステムでも同様に機能します。異なるシステム内ツールに変更する必要なく、ユーザーが汎用ベースイメージを直接インストールすることをサポートします。- 一時的なホームディレクトリー
多くのオペレーティングシステムのデプロイメントでは、永続的でミュータブルかつ実行可能な状態が最小限に抑えられます。これにより、ユーザーのホームディレクトリーが破損する可能性があります。
/homeディレクトリーをtmpfsとして設定すると、再起動後にユーザーデータが確実に消去されます。このアプローチは、一時的な/etcディレクトリーと組み合わせると特に効果的です。たとえば、SSH
authorized_keysやその他のファイルを注入するようにユーザーのホームディレクトリーをセットアップするには、systemdtmpfiles.dスニペットを使用します。f~ /home/user/.ssh/authorized_keys 600 user user - <base64 encoded data>
f~ /home/user/.ssh/authorized_keys 600 user user - <base64 encoded data>Copy to Clipboard Copied! Toggle word wrap Toggle overflow SSH は、
/usr/lib/tmpfiles.d/<username-keys.confとしてイメージ内に埋め込まれています。もう 1 つの例は、ネットワークからキーを取得して書き込むことができる、イメージに埋め込まれたサービスです。これはcloud-initで使用されるパターンです。- UID と GID のドリフト
-
/etc/passwdおよび同様のファイルは、名前と数値識別子間のマッピングです。マッピングが動的で、"ステートレス" なコンテナーイメージビルドと組み合わされると、問題が発生する可能性があります。各コンテナーイメージビルドでは、RPM のインストール順序やその他の理由により、UID が変更される場合があります。当該ユーザーが永続状態を維持する場合、これは問題になる可能性があります。このようなケースに対処するには、sysusers.dを使用するか、DynamicUser=yesを使用するように変換します。