sysadminsはすべての環境のsudoersファイルに存在しますが、他のsudoersは存在しません。環境が異なれば、sudoerもわずかに異なります。ほとんどの場合、ユーザーの90%は同じで、10%は異なるため、すべてに対して1つのsudoersファイルだけを持つことはできません。
現在、sudoers.production1、sudoers.production2、sudoers.production3、sudoers.testing1、sudoers.staging1などの名前の10個の異なるファイルを持つpuppetを使用しています。
次に、Puppetは、サーバーの$ domain(例:dbserver.staging1.acme.com)または$ hardwaremodelに基づいてデプロイするファイルを選択します。正常に動作しますが、非常に多くのファイルを維持するのは悪夢です。
サーバーのドメインに基づいてsudoersファイルを自動生成し、すべてのユーザーとすべての環境に対するすべてのsudoersアクセス許可を持つ1つの大きなファイルのみを使用したいと思います。次のようなもの:
User_Alias ADMINS = abe, bob, carol, dave
case $domain {
"staging1.acme.com" {
#add dev1,dev2,tester1,tester2 to sudoers file
}
"testing2.acme.com" {
#add tester1, tester3, tester4 to sudoers file
}
これについて行くための最良の方法は何ですか?代替案の提案は大歓迎です。ヒントをいただければ幸いです。
アップデート1:
セキュリティ上の理由から、誰かがファイルをそこに(悪意を持ってかどうかにかかわらず)入れて、結合されたファイルを壊したり、何かを挿入したりした場合に備えて、パペットクライアントにあるフォルダーからのファイルの束を連結したくない。
最も重要なことは、使いやすさのために、Puppetサーバー上のsudoers関連ファイル(フラグメントまたは完全)の数を3(prod/stage/test)またはできれば1ファイルに維持したいと考えています。このファイルは(どういうわけか)puppetサーバー上にsudoersファイルを生成し、カスタマイズされた1つのファイルを各puppetクライアントに送信します。
これの目的は、単一のファイルでユーザー名を検索し、11個のファイルで実行するよりもすばやく削除することだけです。多数の環境にユーザーを追加する場合、それほど速くはありませんが、1つのファイルを開いて確認するだけで済み、省略の可能性が大幅に減少します。
sudoバージョンは1.6.9p8であるため、/ sudoers.dフォルダーは使用できず、sudoersファイルのみを使用します。
Update2:
私はいくつかグーグルをしていて、これを見つけました。これは、過去1時間かけて調べたものです。
https://github.com/saz/puppet-Sudo#readme
よくわかりませんが、うまくいくようです。誰かがそれを使用したか、それについて聞いたことがありますか?
Sudoのバージョンは何ですか?お使いのバージョンのSudoは、#includedir
オプションを使用して物事をフラグメントディレクトリ/etc/sudoers.d/
に分割することをサポートしていますか?
もしそうなら、私はあなたがあなたの設定を構築するためにその機能を使用することをお勧めします。
制御するすべてのホストに共通のすべての設定を含むメインの構成ファイルを/etc/sudoers
に配信します。次に、役割固有の構成を/etc/sudoers.d/
内のファイルにドロップします。
各クラスまたはパペットセクションは、そのクラスに直接関連するSudo構成の小さな部分を更新する責任があります。
仮想リソースを見て、理解してください http://docs.puppetlabs.com/guides/virtual_resources.html -これはまさにそれを行います-一部のシステムでは「リソースを実現」し、一部のシステムでは「実現」します。 t。
Puppetテンプレートを使用して行うことができます...必要なユーザー用の小さなRubyスニペット/変数)を使用したサイト固有の構成(後で例を投稿します)
これを処理する従来の方法は、/etc/sudoers
でnamed-usersの代わりにグループ定義を使用することです。管理するのはそれほど面倒ではないかもしれません。