複数回答 は、実際のユーザーを管理するために、puppetの代わりにldapを使用する必要があることを効果的に示しています。私はスケーリングの観点に基づいて同意する傾向があります。新しいスタッフのオンボーディングは、システム管理者が新しいユーザーリソースを追加するのではなく、サポートチームが行う必要があります。
ただし、sshキーと承認済みキー(およびSudoアクセスとユーザー構成ファイル)の管理は、パペットに最適な仕事のようです。
ユーザーごとにキーと構成を管理する標準的な方法は何ですか? puppetはここでLDAPを拡張できますか?従業員が不正になり、1000個の異なるauthorized_keysファイルからキーを取り消す必要がある場合はどうなりますか?
GraigWatsonに同意しません。
アカウントのコピーを作成すると、同期を維持するのに問題が発生します。認証情報の単一のソースを持つことで、多くの複雑さが解消され、LDAPを他のサービス(Web、メールなど)に統合するのがはるかに簡単になります。
Sudoアクセスに関して-個人ではなくグループに基づいてsudoerを構成する場合、施設へのアクセスはLDAPを介して簡単に制御できます。より前向きな計画が必要ですが、長期的には管理がはるかに簡単です。セキュリティを管理しますポリシーデータファイルではありません。
Sshキーを他のマシンで使用できるようにすることは、ある種のネットワークファイルシステムを使用することによって最もよく処理されます-それはNF/Sambaかもしれませんが、複製または共有ファイルシステムは同じ目標を提供します(異なる副作用があります)。
最初のステップは常にセキュリティモデルを定義することです。ローカル構成を許可すると、そのモデルを弱体化させる大きな可能性があります。
実際、PuppetはSPoFを備えていないため(ログインはローカルですが、一元管理されているため)、LDAPよりも優れたソリューションであると言えます。
いずれにせよ、「不正なユーザー」のシナリオでは、キーにssh_authorized_key
Puppetリソースとensure => absent
を使用できます。次に、Mcollective/cronを使用してこれを設定します。
ドキュメントを参照してください: http://docs.puppetlabs.com/references/latest/type.html#sshauthorizedkey
難しいのは、Puppetにユーザーのホームディレクトリ(存在する場合と存在しない場合がある)のファイルを管理させることです。 SSH構成でauthorized_keysファイルの場所をカスタマイズすることでこれを軽減できます(つまり、/var/lib/ssh/authorized_keys/%u
)。
私はとても満足しています: http://www.freeipa.org/page/Main_Page
ユーザー、sudoers、sshキー、さらにはselinux構成など、必要なものがすべて含まれています。