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公開キーベースの認証を使用して、ターゲットインスタンスにアクセスします。 - SSHユーザーがパスワードなしでsudoコマンドを実行できるようにします。 - コマンドではなく時間でアクセスを制限します。 TPAは、クラスターを最初にセットアップするとき、またはメンテナンスウィンドウなどに構成を変更するために\ ``tpaexec deploy`` を再度実行するときのみにアクセスが必要です。それまでは、そのアクセスを完全に無効にすることができますsshとsudoの両方を1行の変更で。 デプロイメント中に、Ansibleが行うことはすべて、プレイブックの動作と指定したパラメーターに基づいて予測可能であり、各アクションは、ターゲットインスタンスのシステムログ、およびtpaexec自分自身が実行されるマシンのAnsibleログに表示されます。 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はシステムで実行されたすべてのプロセスを表示します。ニーズに応じて、これらのことのいずれかまたはすべてを実行できますが、ロギングの増加に伴うオーバーヘッドの増加という明らかな注意事項。 ローカル権限 ------------ :ref:`TPA installation ` sudoは、「run これらのコマンドをroot attemptsで実行する」の短縮形としてのみ言及しています。 TPAがインストールされ、\ ``tpaexec setup`` を実行すると、TPA自分自身はローカルマシンでの昇格した特権を必要としません。ただし、Dockerを使用する場合、Dockerデーモンへの接続が許可されたグループに属するユーザーとしてtpaexecを実行する必要があります。