Ansibleを使用したユーザー管理の現状はどのようなものですか?


10

私は、Ansibleを使用して、大成功を収め、3年ほど前から、増え続けるLinuxシステムの群れを管理しています。質問に入る前に、いくつかの背景を説明する必要があります。

私は1日の仕事の一環として、1つのベンチャー/インキュベーター企業の傘下ですべてを運営するさまざまな企業のシステム設計、展開、および保守を担当しています。私たちのポートフォリオ企業の間には多くの異種交配があり、したがって、ユーザーA、B、CだけがX社のシステムにアクセスする必要があるとは言えません。Y社のシステムへのアクセスも必要になる場合があります。これは、各企業のansible環境が異なるgitリポジトリに存在するという事実によって複雑になります。これは、ユーザーを別の会社のシステムに展開するためのコードの重複が多いことを意味します。ユーザーを特定の会社のシステムにデプロイするために、次のようなコードのブロックをコピーして貼り付けます。

- name: add several users
  user: >
    name={{ item.name }}
    state=present
    groups={{ item.groups }}
    uid={{ item.uid }}
    password={{ item.password }}
    shell=/bin/bash
  with_items:
    - { name: 'user1', groups: 'ssh-access,sudo', uid: '501', password: '<redacted>' }
    - { name: 'user2', groups: 'ssh-access,sudo', uid: '502', password: '<redacted>' }
  tags: users

- name: authorized_keys - user1 
  action: authorized_key user=user1 key="{{ lookup('file', 'pubkeys/user1') }}" manage_dir=yes
  tags:
    - pubkeys
    - users

- name: authorized_keys - user2 
  action: authorized_key user=user2 key="{{ lookup('file', 'pubkeys/user2') }}" manage_dir=yes
  tags:
    - pubkeys
    - users

これは、管理するユーザーが5人未満の場合は問題なく機能しましたが、ユーザーベースが拡大するにつれて、キーローテーションや新しいパスワードなどを使用して最新の状態に保つことがますます困難になります。

私の質問でバックストーリーとコンテキストを設定して、:

一元化された認証システム(LDAPなど)を使用するオプションがないと仮定すると、さまざまなansibleプレイブックが使用できる一元化されたユーザーデータベースの作成にどのように取り組むことができますか?ユーザー、UID、パスワードハッシュ、公開鍵の1つの中央リストを維持し、ユーザー(ホストごとのカスタムグループメンバーシップを使用)を各企業のホストに展開できるようにしたいと考えています。

私は次のような遊びの構造を想定しています:

- name: Deploy users
  user_management:
    - { name: "user1", groups: "sudo" }
    - { name: "user1", groups: "sudo" }

...各ユーザーのuid、ハッシュ、公開鍵は中央のリストから取得され、通常どおり展開されます。

では、どのようなオプションがありますか?私はこれについてかなり長い間検討してきましたが、私がすでにやっていることよりも良いものを思いつくことができませんでした。ユーザーデータベースを保持するカスタムファクトファイルを使用して何かを実行できますか?

回答:


8

演劇とデータを分離する必要があります。

私は、幅広い顧客システムに展開するすべての役割、事実などを含む単一のリポジトリを持っています。すべての役割が再利用可能であり、データがないことを確認します。でhost_vars/fqdn.ymlまたはgroup_vars/customer_name.yml私はその顧客またはリモートシステムに固有のデータを定義します。

私の役割の大部分は、必要に応じて時間をかけて展開され、代わりにすべてを行うのでfrom roles/foo/main.yml、私が持っているroles/foo/debian-foo.ymlroles/foo/openbsd-foo.yml場合にのみ、OSや他の条件が一致するものを含まれています。

簡略化して、roles/adduser/main.ymlこれを含めることができます:

- user: name={{ item.name }} ...
  with_items:
  - customer_users

そしてgroup_vars/ACME.yml、これを含めることができます

customer_users:
- name: sausage
   uid: 32153
- name: beans
   uid: 1024

あなたの場合、rolesフォルダーがすべての顧客で同一の共有サブモジュールである限り、それぞれのgitリポジトリに別々のansible環境があることは問題ないかもしれません。


これは私を正しい方向に向けます。アレックス、ありがとう!さまざまな役割やグループから参照できるユーザー名/キー/ uidsなどの単一のデータベースを維持する方法を整理する必要がありますが、それを実現する方法についてはいくつかのアイデアがあると思います。
EEAA

1
@EEAA覚えています。roles/ allはファイルを含むディレクトリにできるため、roles / all / staff.yml、roles / all / foo.ymlなどを簡単に一元化できます
Alex Holst
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.