2.4. Day 2 オペレーション
Day 2 オペレーションには、ホスト、プロジェクト、環境レベルの維持を含むクラスターのヘルスチェックとスケーリングチェックが含まれます。設定とセキュリティーのドリフトを継続的に分析する必要があります。
2.4.1. RBAC に関する考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
管理者は、プラットフォームゲートウェイに組み込まれている ロールベースのアクセス制御 (RBAC) を使用して、サーバーインベントリー、組織などへのアクセスを委譲できます。管理者はさまざまな認証情報の管理を一元化することもできます。管理を一元化することで、エンドユーザーが必要なシークレットをエンドユーザー自身に表示することなく使用できるようになります。RBAC コントロールを使用すると、Ansible Automation Platform でセキュリティーを強化し、管理を効率化できます。
RBAC は、ユーザーまたはチームにロールを付与する方法です。RBAC は、ロールの観点から考えるのが最も簡単です。ロールは、特定の機能が設定されている “オブジェクト” を、誰または何が参照、変更、または削除できるかを正確に定義したものです。
Ansible Automation Platform の RBAC 設計に関して、理解しておくべき主要な概念は、ロール、リソース、ユーザーです。ユーザーはロールのメンバーになることができます。これにより、そのロールに関連付けられたリソース、または “子孫” ロールに関連付けられたリソースへの特定のアクセスが許可されます。
ロールは実質的には機能の集合です。ユーザーには、割り当てられているロール、またはロール階層を通じて継承したロールを通じて、これらの機能および Automation Controller のリソースへのアクセスが許可されます。
ロールは、機能のグループをユーザーのグループに関連付けます。機能はすべて、ロール内のメンバーシップから得られます。ユーザーは、割り当てられているロールを通じて、またはロール階層を通じて継承したロールを通じてのみ機能を受け取ります。ロールのすべてのメンバーは、そのロールに付与されたすべての機能を持ちます。組織内において、ロールは比較的一定ですが、ユーザーと機能は両方とも多数あり、短期間で変更されることがあります。ユーザーは多くのロールを持つことができます。
ロール階層、アクセス継承、組み込みロール、権限、ペルソナ、ロール作成などの詳細は、ロールベースのアクセス制御によるアクセス管理 を参照してください。
以下は、ロールとリソース権限を使用する組織の例です。
図2.2 Automation Controller 内の RBAC ロールのスコープ
ユーザーアクセスは、特定のユーザーへの権限の個別割り当てではなく、システムオブジェクト (ユーザー、グループ、名前空間) に対する権限の管理に基づいています。権限は、作成するグループに割り当てることができます。グループを作成したら、グループにユーザーを割り当てることができます。グループ内の各ユーザーは、そのグループ内に割り当てられた権限を持つことになります。
Automation Hub で作成されるチームは、内部コレクションの管理、ユーザーアクセスの設定、リポジトリー管理を担当するシステム管理者から、内部で開発されたコンテンツを整理して Automation Hub にアップロードするためのアクセス権を持つグループまで多岐にわたります。
表示専用アクセスを有効にすると、Private Automation Hub のロックダウンをさらに強化できます。表示専用アクセスを有効にすると、Private Automation Hub のコレクションまたは名前空間をログイン不要で表示できる権限をユーザーに付与できます。表示専用アクセスを使用すると、ソースコードの表示またはダウンロードだけにユーザーの能力を制限して、Private Automation Hub 上で編集する権限を与えることなく、権限のないユーザーとコンテンツを共有できます。Red Hat Ansible Automation Platform インストーラーにあるインベントリーファイルを編集して、Private Automation Hub の表示専用アクセスを有効にします。
2.4.2. 更新とアップグレード リンクのコピーリンクがクリップボードにコピーされました!
すべてのアップグレードは、現在アップグレード先のメジャーバージョンより 1 つまたは 2 つ下のバージョンである必要があります。たとえば、Automation Controller 4.3 にアップグレードするには、バージョン 3.8.x 以前からの直接アップグレードパスがないため、まずバージョン 4.1.x にする必要があります。詳細は、Upgrading to Ansible Automation Platform を参照してください。Automation Controller 4.3 を実行するには、Ansible 2.12 以降も必要です。
2.4.2.1. 障害復旧と運用の継続性 リンクのコピーリンクがクリップボードにコピーされました!
Ansible Automation Platform の定期的なバックアップは、障害復旧計画の重要な部分です。バックアップと復元はどちらもインストールプログラムを使用して実行します。そのため、これらの操作は、このドキュメントで前述した専用のインストールホストから実行する必要があります。これらの操作の実行方法の詳細は、Automation Controller ドキュメントの Backing Up and Restoring セクションを参照してください。
重要な点として、バックアップにはデータベースのコピーと、データベースに保存されている認証情報の復号化に使用されるシークレットキーが含まれています。そのため、バックアップファイルは暗号化されたセキュアな場所に保存する必要があります。これにより、エンドポイントの認証情報へのアクセスが適切に保護されます。バックアップへのアクセスは、Automation Controller および専用インストールホストへの root シェルアクセス権を持つ Ansible Automation Platform 管理者のみに制限する必要があります。
Ansible Automation Platform 管理者が Ansible Automation Platform 環境をバックアップする必要がある主な理由は、次の 2 つです。
- Ansible Automation Platform 環境からデータのコピーを保存し、必要に応じて復元できるようにするため。
- 新しい Ansible Automation Platform クラスターを作成する場合、またはアップグレードの準備をしている場合に、バックアップを使用して環境を別のサーバーのセットに復元するため。
どのような場合でも、推奨される最も安全なプロセスは、環境のバックアップと復元に常に同じバージョンの PostgreSQL と Ansible Automation Platform を使用することです。
システムで冗長性を使用することを強く推奨します。シークレットシステムがダウンしていると、Automation Controller が情報を取得できず、サービスが復元されれば回復できるような障害が発生する可能性があります。Automation Controller によって生成された SECRET_KEY が侵害されており、再生成する必要があると思われる場合は、Automation Controller のバックアップおよび復元ツールとよく似た動作をするツールをインストールプログラムから実行できます。
新しいシークレットキーを生成するには、次の手順を実行します。
- Ansible Automation Platform データベースのバックアップを、他の操作を行う前に必ず実行します。Backing Up and Restoring Controller セクションで説明されている手順に従ってください。
-
インストールのインベントリー (バックアップ/復元の実行に使用したのと同じインベントリー) を使用して、
setup.sh -kを実行します。
以前のキーのバックアップコピーは /etc/tower/ に保存されます。
2.4.3. HashiCorp Vault を使用した外部シークレット管理 リンクのコピーリンクがクリップボードにコピーされました!
HashiCorp Vault を Ansible Automation Platform と統合して、機密データを管理および取得できます。
2.4.3.1. Ansible Automation Platform を HashiCorp Vault と通信するように設定する リンクのコピーリンクがクリップボードにコピーされました!
エンタープライズ環境において、シークレットを外部で管理することは、複数のサービスにまたがる機密データを管理するうえで便利な方法です。HashiCorp Vault の最も一般的かつ推奨される認証方法の 1 つは、AppRoles と、トークンが発行される前に満たす必要があるポリシーおよびログイン要件を使用することです。HashiCorp Vault に保存されているシークレットを使用するように Ansible Automation Platform を設定するには、HashiCorp Vault Secret Lookup タイプの新しい認証情報を設定します。これを実行する方法については、HashiCorp Vault Secret Lookup を参照してください。
特定可能な認証情報名、組織、Vault サーバーの URL (例: https://vault.domain.com:8200) などの関連情報を入力します。
必要なフィールドに、トークン、AppRole の role_id、AppRole の secret_id などの情報を入力し、API バージョンとして v2 を選択します。
認証情報をテストして機能と動作をテストするには、次の手順を使用します。
手順
- Create Credential をクリックする前に、 をクリックします。
ポップアップボックスで、Path to Secret と Key Name を入力します。
注記キーと値のペアを保存する場合、Path to Secret の先頭に
kvが付きます (例:kv/key_name)。- をクリックします。
- テストが成功したら、 をクリックします。
- 完了すると、Ansible Automation Platform が、HashiCorp Vault を外部シークレットソースとして使用するように適切に設定されます。
2.4.3.2. Ansible Automation Platform 内で HashiCorp Vault の認証情報を使用する リンクのコピーリンクがクリップボードにコピーされました!
Ansible Automation Platform 内で HashiCorp Vault 認証情報を使用するには、Machine Credential タイプの新しい認証情報を作成します。特定可能な認証情報名や組織などの関連情報を入力します。
HashiCorp Vault 認証情報の使用を設定するには、次の手順を使用します。
手順
-
Username を設定するために、
アイコンをクリックします。
- ステップ 1 で作成した HashiCorp Vault 認証情報を選択します。
- Path to Secret と Key Name を入力します。
- 必要に応じて、 をクリックします。それ以外の場合は、 をクリックします。
2.4.3.3. マシン認証情報の SSH 秘密鍵の設定 リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を使用してください。
手順
-
Username を設定するために、
アイコンをクリックします。
- 作成した HashiCorp Vault 認証情報を選択します。
- Path to Secret と Key Name を入力します。
- Key Name として秘密鍵の名前を選択します。
- 必要に応じて、 をクリックします。それ以外の場合は、 をクリックします。