Kerberos は、ドメイン環境で Windows サーバーを管理する場合によく使用される認証方法です。Red Hat Ansible Automation Platform では、今まで何年にもわたって Kerberos 認証を活用できるようにしてきました。ではなぜ、改めて取り上げる必要があるのでしょうか。
Ansible Automation Platform 2 は 2021 年 7 月にリリースされ、プラットフォームのアーキテクチャが大幅に再構築されました。根本的な変更の 1 つは、automation execution environment の導入でした。これは、コンテナを使用して Ansible Playbook を一貫してパッケージ化、配布、実行するものです。簡単に言うと、automation execution environment は RHEL ベースイメージ、Ansible Core、および Ansible による自動化の実行に必要なあらゆる依存関係 (通常は Ansible Content Collections と Python ライブラリ) で構成されます。
コンテナに移行した場合、時として localhost がコンテナになったことを考慮する必要があります。automation execution environment に関して localhost は見かけどおりではないことについては、詳しく説明している優れたブログ記事があるのでご覧ください。
これらをすべて考慮した上で、Ansible Automation Platform 2 で Kerberos 認証を設定する方法、設定をテストする方法、Kerberos を使用するように automation controller を設定する方法について、ガイド付きの例を見ていきます。
設定例
Ansible で Kerberos を使用するには、Kerberos 設定ファイルが必要です。設定ファイルの内容は、DNS 設定、KDC 検出、ドメインの数などの要素によって異なります。この例では、automation controller サーバーで検出できない DEMOLAB.LOCAL という単一のドメインがあります。
以下は、Kerberos クライアントの設定例です。Automation Controller Administration Guide には同様の例が記載されています。
[libdefaults]
rdns = false
default_realm = DEMOLAB.LOCAL
[realms]
DEMOLAB.LOCAL = {
kdc = ms-ad.demolab.local
admin_server = ms-ad.demolab.local
}次に、automation execution environment について検討する必要があります。localhost は見かけどおりではないことを忘れないでください。automation controller が Ansible Playbook を実行すると、コンテナイメージが呼び出されます。このコンテナイメージは、コントローラーノードの基盤となるファイルシステムにアクセスできません。実行環境が Kerberos クライアント設定にアクセスできることを確認する必要があります。これを実行するには 2 つの方法があります。
- automation controller から実行されている実行環境に Kerberos クライアント設定をマッピングする
- Ansible Builder を使用して独自の実行環境をカスタマイズして構築し、krb5.conf をイメージに追加する
この例では、実行されている実行環境に Kerberos クライアント設定をマッピングします。他に変更を加える必要がないからです。
ファイルを実行環境にマッピングするために、automation controller サーバーにある /etc/krb5.conf.d/DEMOLAB.LOCAL.conf という Kerberos クライアント設定ディレクトリに設定を書き込みます。
# cat /etc/krb5.conf.d/DEMOLAB.LOCAL.conf
[libdefaults]
rdns = false
default_realm = DEMOLAB.LOCAL
[realms]
DEMOLAB.LOCAL = {
kdc = ms-ad.demolab.local
admin_server = ms-ad.demolab.local
}
コマンドラインからのテスト
コマンドラインから設定を確認する準備ができました。まず、どの実行環境をテストに使用できるか確認しましょう。automation controller サーバーで awx ユーザーに切り替えて、実行環境イメージを一覧表示します。ここでは、ee-supported-rhel8 実行環境が利用可能であることを確認できます。これはテストに使用したいイメージです。
$ su - awx
$ podman images
REPOSITORY TAG IMAGE ID CREATED SIZE
registry.redhat.io/ansible-automation-platform-23/ee-supported-rhel8 latest 024856bccc5f 4 weeks ago 1.66 GB 別のイメージを使用してテストする必要がある場合は、「podman pull」を使用してコンテナレジストリから関連イメージをコピーします。
次に、設定ディレクトリを実行環境にマッピングし、認証して Kerberos チケットを取得できるかどうかを確認します。次の Podman コマンドは、実行環境コンテナを起動し、実行中のコンテナに /etc/krb5.conf.d/ をマッピングします。また、kinit をテストできるように、コンテナ内の対話型シェルも利用できます。最後に一点、Kerberos は認証情報キャッシュを使用して有効な Kerberos 認証情報を保持します。繰り返しますが、localhost はここでは見かけどおりではないので、ファイルシステムと Kerberos キャッシュにはアクセスできません。構成をテストできるように、KRB5CCNAME 変数を設定して一時的な Kerberos 認証情報キャッシュを作成します。winrm 接続プラグインも同様のメカニズムを使用します。
$ podman run --rm -v "/etc/krb5.conf.d:/etc/krb5.conf.d:O" -it registry.redhat.io/ansible-automation-platform-23/ee-supported-rhel8:latest /bin/bash
bash-4.4# export KRB5CCNAME=`mktemp`
bash-4.4# echo $KRB5CCNAME
/tmp/tmp.ZzBXbtGiV1
bash-4.4# kinit svc-ansible@DEMOLAB.LOCAL
Password for svc-ansible@DEMOLAB.LOCAL:
bash-4.4# klist
Ticket cache: FILE:/tmp/tmp.ZzBXbtGiV1
Default principal: svc-ansible@DEMOLAB.LOCAL
Valid starting Expires Service principal
04/04/23 14:01:37 04/05/23 00:01:37 krbtgt/DEMOLAB.LOCAL@DEMOLAB.LOCAL
renew until 04/11/23 14:01:33 さらなるテストとして、チケットが特定のサーバーに対する認証について機能するかどうかを検証できます。実行環境で kinit を正常に実行できた後、kvno を使用してターゲットホストで認証を行うことができます。この例では、チケットを使用して windows2.demolab.local で認証できることを確認しましょう。
bash-4.4# kvno http/windows2.demolab.local
http/windows2.demolab.local@DEMOLAB.LOCAL: kvno = 1
bash-4.4# klist
Ticket cache: FILE:/tmp/tmp.pe2PBReLm5
Default principal: svc-ansible@DEMOLAB.LOCAL
Valid starting Expires Service principal
05/10/23 15:26:35 05/11/23 01:26:35 krbtgt/DEMOLAB.LOCAL@DEMOLAB.LOCAL
renew until 05/17/23 15:26:33
05/10/23 15:26:49 05/11/23 01:26:35 http/windows2.demolab.local@DEMOLAB.LOCAL
renew until 05/17/23 15:26:3テストは問題ないようです。それでは設定を automation controller に移行しましょう。
automation controller の設定
使用する Windows アカウントについて、automation controller に Machine 認証情報を追加する必要があります。これは「username@DOMAIN.COM」形式のユーザープリンシパル名 (UPN) である必要があります。automation controller に認証情報を追加するには、左側のメニューの [Credentials] に移動して [Add] を押し、認証情報タイプとして「Machine」を選択します。次のようにドメインユーザーとパスワードを入力します。
次に、実行環境に Kerberos クライアント設定をマッピングします。管理者は、[Settings] -> [Job Settings] を設定し、[Paths to expose to isolated jobs] を編集して、Kerberos ディレクトリを追加する必要があります。これは CLI からテストしたときに使用した形式と同じであることに注意してください。新しい設定は次のようになります。
テストの準備ができました。シンプルな “ping” Playbook を使用して設定を検証できます。ログ出力を増やして、WinRM 接続メッセージを含めることもできます。ジョブテンプレートを編集し、詳細度をレベル 5 に設定します。
ジョブテンプレートを起動すると、詳細な接続メッセージが表示されます。
一時的な Kerberos 認証情報キャッシュが作成され、アカウントが認証できるようになって、チケットを取得していることが確認できます。Playbook は正常に完了します。
トラブルシューティング
実行環境で Kerberos を設定するときにエラーメッセージが表示される場合があります。表示される可能性のあるエラーの一部と、その解決策を以下に示します。
- Included profile directory could not be read while initializing Kerberos 5 library:これは、/etc/krb5.conf.d ディレクトリにある設定ファイルが、実行環境がアクセスできない追加のディレクトリを登録しようとしていることを示している可能性があります。/etc/krb5.conf.d に、includedir オプションを含む設定ファイルがないか、確認してください。
- Invalid UID in persistent keyring name while getting default ccache:一時的な認証情報キャッシュディレクトリを、必ず前述のように設定してください。
- Cannot find KDC for realm "<DOMAIN>" while getting initial credentials: このエラーには、さまざまな理由が考えられます。Kerberos 設定が正しく、有効な KDC が設定に記述されていることを確認します。KDC のルックアップに DNS を使用している場合は、dns_lookup_kdc が true に設定されていることを確認します。
- Server not found in Kerberos database:これは多くの場合、DNS の問題か、Ansible インベントリーの設定が間違っていることが関連している可能性があります。インベントリーのホスト名が DNS のサーバー名と一致することを確認してください。また、WinRM デバッグログを使用して、Ansible が FQDN を使用してホストに接続しようとしていることを確認します。以下は、ansible_host 変数が Windows サーバーに設定され、ホスト名ではなく IP への接続を試みている例です。
次のステップ
この例が、Ansible Automation Platform 2 のいくつかの変更点と、Windows サーバーの管理で Kerberos 認証を使い始める方法を理解する上でお役に立てば幸いです。Windows は今後も Ansible で重視され、使いこなすのに役立つリソースは他にも用意されています。
- Windows 向けの Ansible:Ansible を使用して Windows インフラストラクチャや一般的なユースケースを管理する方法を説明しています。
- トライアル・サブスクリプション:準備が整ったら、トライアル・サブスクリプションを取得しましょう。Ansible Automation Platform のすべてのコンポーネントに無制限にアクセスできます。
執筆者紹介
類似検索
New efficiency upgrades in Red Hat Advanced Cluster Management for Kubernetes 2.15
Revolutionizing learning: How Ford's Kubernetes community sparks technological innovation
Technically Speaking | Build a production-ready AI toolbox
AI Is Changing The Threat Landscape | Compiler
チャンネル別に見る
自動化
テクノロジー、チームおよび環境に関する IT 自動化の最新情報
AI (人工知能)
お客様が AI ワークロードをどこでも自由に実行することを可能にするプラットフォームについてのアップデート
オープン・ハイブリッドクラウド
ハイブリッドクラウドで柔軟に未来を築く方法をご確認ください。
セキュリティ
環境やテクノロジー全体に及ぶリスクを軽減する方法に関する最新情報
エッジコンピューティング
エッジでの運用を単純化するプラットフォームのアップデート
インフラストラクチャ
世界有数のエンタープライズ向け Linux プラットフォームの最新情報
アプリケーション
アプリケーションの最も困難な課題に対する Red Hat ソリューションの詳細
仮想化
オンプレミスまたは複数クラウドでのワークロードに対応するエンタープライズ仮想化の将来についてご覧ください