Skip to Content
Building Osイメージ内ユーザー

イメージ内ユーザー

ユーザー記録は os.users にあります。イメージ内にアカウントを作成します。OpenFactory の Web サイト アカウントや組織の役割とは無関係です。

正規の形状

{ "os": { "users": [ { "username": "deploy", "full_name": "Deployment Operator", "groups": ["sudo"], "shell": "/bin/bash" } ] } }

対応フィールドには username、任意の passwordfull_namegroupsshell、および Elster/Vyatta イメージが使うターゲット固有の level があります。homecomment を含む古い例は正規モデルと一致せず、無視されることがあります。

ユーザー名とグループ名は、安全な Linux アカウント文字と長さに制限されます。シェルは、空白やシェルメタ文字を含まない絶対パスでなければなりません。

パスワードの動作

password を未設定のままにすると、パスワードがロックされたアカウントが作成されます。鍵のみの SSH、初回ブートのエンロールメント、デプロイ時のアイデンティティ統合では、これが望ましいレシピ状態です。

平文パスワードを含めると、それは機微なビルド入力になり、保存されたレシピ、ログ、エクスポートを通じて露出することがあります。実運用の資格情報をレシピに使わないでください。Phone レシピは、資格情報をイメージに焼き込むのではなく、デバイス上で収集しなければなりません。

SSH のパスワード認証を無効にする前に、承認済みの公開鍵または別のアクセス方法が存在し、テスト済みであることを確認してください。そうしないと、正しく強化されたイメージに入れなくなることがあります。

グループと特権

  • sudowheel は、ディストリビューションによって管理権限を付与できます。
  • docker は、デーモン ソケットを通じて root 相当の制御を与えることがよくあります。
  • kvm は、存在する場合に仮想化デバイスへのアクセスを与えます。
  • adm は、機微なログを露出できます。

これらを特権グループとして扱い、アカウントが必要とするものだけを付与してください。ディストリビューション固有のグループ名は移植できません。

サービス アカウント

対話しないサービス アカウントでは、対象で利用できるログイン不可シェルを選び、管理グループを省略してください。ジェネレーターとサービス ユニットが意図したアイデンティティを保つことを確認してください。groups を省略するとレシピの既定が sudo を追加することがあるため、適切な場合は空のグループ一覧を明示してください。

検証

重要な正確な性質をテストしてください。

  • アカウントが期待する UID 範囲で存在する;
  • プライマリ グループと補助グループが正しい;
  • ログイン シェルとパスワード ロック状態が正しい;
  • 他で生成される場合、ホームとファイル所有者が正しい;
  • 未承認の sudo とサービス アクセスが拒否される; そして
  • 承認済みのログインまたはエンロールメント経路が成功する。

アカウント作成だけから最小特権を推論しないでください。