TPA, Ansible, and sudo

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構成#

デフォルトでは、TPAはターゲットインスタンスでのsudo関連の構成を自動的に管理します。これには、sudoパッケージが存在しない場合のインストール、さまざまなコンポーネントのsudoersファイルの構成が含まれます。

privilege_escalation_command のデフォルト値は"sudo" で、これにより、TPAはsudoのインストールと構成を管理できます。

代替の特権エスカレーションコマンドを使用する#

環境が別の特権エスカレーションコマンドを使用している場合、 cluster_vars でprivilege_escalation_command を設定することにより、代替を使用するようにTPAを構成できます。

cluster_vars:
  privilege_escalation_command: other_tool  # replaces sudo; may include arguments

この値は、TPAが管理対象アプリケーションに対して生成する各特権エスカレーションコマンドでsudo の直接インプレース置換として使用されます。必要に応じて追加の引数たとえば other_tool --flag などを含めることができます。

Ansibleのbecomeメカニズムでサポートされている任意の特権エスカレーションコマンドに設定できます。 Ansible privilege escalation documentation を参照してください

サポートされているメソッドの完全なリストについては、

重要: sudo は、EDBで公式にサポートされている唯一の特権エスカレーションコマンドです。代替コマンドを使用する場合、互換性と適切な構成を保証するのは自分の責任です。 EDBサポートは、代替の特権エスカレーションメカニズムに関連する問題を支援する能力が制限されている場合があります。

Ansibleのbecomeメソッドとprivilege_escalation_command#

注意する必要がある2つの別個の特権エスカレーション設定があります。

  • ``ansible_become_method`` は、ターゲットインスタンスでデプロイメントタスクを実行するときにAnsible自分自身が特権をエスカレートする方法を制御します。これは、インベントリまたはansible.cfg に設定されたAnsible変数です。

  • ``privilege_escalation_command`` は、管理対象アプリケーションEFM、repmgr、 HARPが実行時に呼び出すコマンドを制御して、Ansibleとは無関係に、サービス管理操作の特権をエスカレートします。

これらは目的が異なるため、両方を一貫して構成する必要があります。環境がsudoの代わりに代替ツールを使用している場合、cluster_vars でprivilege_escalation_command を設定し、 および Ansibleインベントリまたはansible.cfg でansible_become_method と一致するようにansible.cfg を構成する必要があります。

推奨されるアプローチ フックを使用する#

別の特権エスカレーションコマンドを使用する必要がある場合は、 TPA hooks を使用して特権エスカレーションメカニズムを構成することをお勧めします。フックを使用すると、展開中の特定のポイントでカスタムタスクを実行でき、カスタマイズをTPAのコア展開ロジックから分離したまま、特権エスカレーションの構成を完全に制御できます。

たとえば、リポジトリを構成した後、 post-repo フックを使用して特権エスカレーションコマンドをインストールおよび構成したり、 pre-deploy フックを使用して、メイン展開が開始される前に必要な権限を設定したりできます。このアプローチにより、保守性が向上し、環境固有の要件の管理が簡単になります。

手動構成要件#

代替の特権エスカレーションコマンド"sudo" 以外の場合、TPAはsudoパッケージのインストールとsudoers構成をスキップします。 tpaexec deploy を実行する前に、選択した特権エスカレーションコマンドをすべてのターゲットシステムに手動またはフックを使用してインストールして構成する必要があります。

1. postgresユーザー のサービス管理権限

特権エスカレーションメカニズムでは、 postgres systemユーザーがPostgreSQLおよび関連サービスを起動、停止、再起動、およびリロードするためのsystemctlコマンドを実行できるようにする必要があります。これは、フェールオーバーマネージャー repmgr、 HARP、EFMが自動フェイルオーバー操作中に正常に機能するために必要です。

たとえば、sudoを使用すると、TPAは次の権限を構成します。

postgres ALL=(ALL) NOPASSWD: /bin/systemctl start postgresql
postgres ALL=(ALL) NOPASSWD: /bin/systemctl stop postgresql
postgres ALL=(ALL) NOPASSWD: /bin/systemctl restart postgresql
postgres ALL=(ALL) NOPASSWD: /bin/systemctl reload postgresql

選択した特権エスカレーションシステムで同等の権限を構成する必要があります。

2. EFMデータベース機能の権限EFMクラスターのみ

クラスターがフェールオーバーマネージャーとしてEFMを使用している場合、特権エスカレーションメカニズムは、EFMシステムユーザーがpostgresユーザーとしてefm_db_functions スクリプトを実行できるようにする必要があります。これは、EFMがヘルスチェックとフェイルオーバー操作を実行するために必要です。

たとえば、sudoを使用すると、TPAは次のように構成します。

efm ALL=(postgres) NOPASSWD: /usr/edb/efm-X.Y/bin/efm_db_functions

特権エスカレーションシステムで同等の権限を構成して、efmユーザーがpostgresユーザーとしてこのスクリプトを実行できるようにします。

ロギング#

プレイブックの実行の場合、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を実行する必要があります。

目次