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 つの方法があります。

  1. automation controller から実行されている実行環境に Kerberos クライアント設定をマッピングする
  2. 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 のすべてのコンポーネントに無制限にアクセスできます。

 


執筆者紹介

Pat Harrison works for Red Hat in the UK as an Associate Principal Specialist Solution Architect focused on Ansible automation. Prior to this, Pat worked as a Red Hat Consultant helping to deliver solutions across various Red Hat products.
UI_Icon-Red_Hat-Close-A-Black-RGB

チャンネル別に見る

automation icon

自動化

テクノロジー、チームおよび環境に関する IT 自動化の最新情報

AI icon

AI (人工知能)

お客様が AI ワークロードをどこでも自由に実行することを可能にするプラットフォームについてのアップデート

open hybrid cloud icon

オープン・ハイブリッドクラウド

ハイブリッドクラウドで柔軟に未来を築く方法をご確認ください。

security icon

セキュリティ

環境やテクノロジー全体に及ぶリスクを軽減する方法に関する最新情報

edge icon

エッジコンピューティング

エッジでの運用を単純化するプラットフォームのアップデート

Infrastructure icon

インフラストラクチャ

世界有数のエンタープライズ向け Linux プラットフォームの最新情報

application development icon

アプリケーション

アプリケーションの最も困難な課題に対する Red Hat ソリューションの詳細

Virtualization icon

仮想化

オンプレミスまたは複数クラウドでのワークロードに対応するエンタープライズ仮想化の将来についてご覧ください