TPA, Ansible, and sudo#

TPAはsudoでAnsibleを使用して、ターゲットインスタンスで昇格した特権でタスクを実行します。このページでは、Ansibleがsudoを使用する方法決してTPA固有ではありません、およびTPAで管理されているシステムへの影響について説明します。

TPAにはroot権限が必要です。

パッケージをインストールするためオペレーティングシステムのネイティブパッケージマネージャーを使用した必須パッケージ、およびpipを使用したオプションパッケージ
サービスを停止、リロード、および再起動するためPostgres、repmgr、efm、etcd、haproxy、pgbouncerなど
他のさまざまなタスクを実行するためたとえば、クラスターファクトの収集、スイッチオーバーの実行、クラスターノードのセットアップ

TPAはsudoを使用できることも必要です。 ansible_user: root を設定することにより、rootとして直接sshインすることができますが、引き続きsudoを使用して他のユーザーpostgresなどとしてタスクを実行します。

Ansible sudo呼び出し#

Ansibleがsudoを使用してタスクを実行すると、ターゲットインスタンスに次のようなプロセスが表示されます。

/bin/bash -c sudo -H -S -n  -u root /bin/bash -c \
  ""echo BECOME-SUCCESS-kfoodiiprztsyerriqbjuqhhbemejgpc ; \
  /usr/bin/python2"" && sleep 0

sudo yum install -y xyzpkg のようなものを期待していた人は、これに驚くことがよくあります。一般に、Ansibleのほとんどのタスクは、認識可能なシェルコマンドを実行するのではなく、Pythonインタープリターを呼び出してPythonコードを実行します。 Playbookはraw シェルコマンドを実行できますが、TPAはそのようなタスクをPythonインタープリターをブートストラップするためにのみ使用します。

Ansibleモジュールには、さまざまな複雑さのPythonコードが含まれており、AnsibleプレイブックはYAML形式で書かれた単なるシェルスクリプトではありません。任意のAnsibleプレイブックを実行するのと同じことを行うシェルコマンドを「抽出」する方法はありません。

Ansibleがsudo privilegeescalation must be general を使用する方法の重要な結果が1つあります。つまり、一部の管理者が慣れているように、sudoers.confでsudo呼び出しを特定のコマンドに制限することはできません。ほとんどのタスクはPythonを呼び出すだけです。すべてのコマンドにランダムな文字列がなければ、Pythonへのsudoアクセスを制限できますが、Pythonがrootとして実行されると、とにかくできることに対する事実上の制限がありません。

ターゲットホストでPythonモジュールを実行するのは、Ansibleの動作です。これはどれもTPAに固有ではなく、これらの考慮事項は他のAnsibleプレイブックに等しく適用されます。

SSHおよびsudoパスワード#

パスワードなしのSSHキー認証とパスワードなしのsudoアクセスを設定することを強くお勧めしますが、パスワードを使用することも可能です。

tpaexecを実行する前に環境でANSIBLE_ASK_PASS=yes およびANSIBLE_BECOME_ASK_PASS=yes を設定すると、Ansibleはリモートサーバーのログインパスワードとsudoパスワードを入力するように求めます。次に、リモートサーバーでlogin/sudoパスワードプロンプトをネゴシエートし、指定したパスワードを送信しますこれにより、Playbookの実行時間が著しく長くなります。

パスワードの組み合わせを使用してアクセスを制限するよりも、必要がないときに特定のアカウントを介したアクセスを完全に無効にする方が効果的なセキュリティ制御であると考えられるため、この操作モードはお勧めしません。 sshの公開キー認証を使用すると、サーバーにアクセスできる人を効果的に制御できます。許可されたユーザーごとに1つのプライベートキーを保護することは、1つまたは複数の共有パスワードを保護するよりも簡単です。また、ssh / sudoレベルでのアクセスを必要な場合に制限すると、メンテナンス期間にパスワードは追加のセキュリティを追加しません。

sudoオプション#

sudoでAnsibleを使用するには、sudoers.confでrequiretty を設定しないでください。

必要に応じて、ansible.cfgの[privilege_escalation] セクションでbecome_flags 、または環境のANSIBLE_BECOME_FLAGS 、またはインベントリのansible_become_flags を設定することにより、Ansibleが使用するsudoオプション-H -S -n を変更できます。 3つの方法はすべて同等ですが、特定の必要がある場合にのみsudoオプションを変更してください。デフォルトが選択されたのには十分な理由があります。たとえば、パスワードなしのsudoが誤って構成されている場合、-S -n を削除するとタスクがタイムアウトします。

ロギング#

プレイブックの実行の場合、sudoログは主にPythonの呼び出しを表示します誰かがsudo -i を使用するときにbashの呼び出しのみを表示するのと同様に。

詳細については、syslogには、ターゲットインスタンスでの各モジュール呼び出しの正確な引数が表示されます。そのモジュールが呼び出された理由の高レベルのビューについては、コントローラのansible.logに、そのタスクがしようとしたことと結果が表示されます。

さらに詳細な監査データの独立したソースが必要な場合は、サーバーでauditdを実行し、SELinuxログファイルを使用できます。 bpftrace/bccからさらに詳細なシステムコールレベルの情報を取得できます。たとえば、opensnoopはシステムで開かれているすべてのファイルを表示し、execsnoopはシステムで実行されたすべてのプロセスを表示します。ニーズに応じて、これらのことのいずれかまたはすべてを実行できますが、ロギングの増加に伴うオーバーヘッドの増加という明らかな注意事項。

ローカル権限#

TPA installation

sudoは、「run これらのコマンドをroot attemptsで実行する」の短縮形としてのみ言及しています。 TPAがインストールされ、tpaexec setup を実行すると、TPA自分自身はローカルマシンでの昇格した特権を必要としません。ただし、Dockerを使用する場合、Dockerデーモンへの接続が許可されたグループに属するユーザーとしてtpaexecを実行する必要があります。

TPA, Ansible, and sudo

目次