第3章 API 呼び出しの認証
Satellite API との対話には認証が必要です。各 API 要求で使用するローカルホストに Satellite Server CA 証明書をダウンロードして、SSL 認証を提供できます。各 API リクエストには、有効なユーザー名とパスワードも必要です。これらについては、以下のセクションで説明します。
3.1. SSL 認証の使用
Red Hat Satellite は HTTPS を使用して、Red Hat Satellite Server との通信時に、一定の暗号化およびアイデンティティーの検証を行います。SSL 以外の通信は、Satellite 6 ではサポートされていません。
各 Red Hat Satellite Server は自己署名証明書を使用します。この証明書は、暗号化キーを検証するサーバー証明書および Satellite Server のアイデンティティーを信頼する証明局のロールを果たします。以下の手順は、Satellite Server に SSL 認証を設定する方法を説明します(この場合は satellite6.example.com)。
- 以下のオプションのいずれかを使用して、通信する Satellite Server (satellite6.example.com)から証明書を取得します。
- SSH を使用して証明書を取得するには、以下のコマンドを実行します。
$ scp root@satellite6.example.com:/var/www/html/pub/katello-server-ca.crt ./
- コマンドを Satellite Server で直接実行する場合は、以下のコマンドを実行してローカルで利用可能なコピーから証明書を取得します。
$ cp /var/www/html/pub/katello-server-ca.crt ./
- HTTP を使用して証明書を取得するには、以下のコマンドを実行します。
$ curl -O http://satellite6.example.com/pub/katello-server-ca.crt
警告暗号化されていない HTTP 接続を使用して証明書を取得すると、セキュリティーリスクにさらされる可能性があります。
- クライアント上の証明書を認証局として使用して、Satellite Server の ID を検証します。
$ curl -X GET -u sat_username:sat_password \ -H "Accept:application/json" --cacert katello-server-ca.crt \ https://satellite6.example.com/katello/api/organizations
GET はデフォルトのアクションであるため、ここで は GET 属性を省略することができます。 - Network Security Services (NSS) データベースを作成して証明書を保存します。
$ certutil -N -d sql:$HOME/.pki/nssdb Enter a password which will be used to encrypt your keys. The password should be at least 8 characters long, and should contain at least one non-alphabetic character. Enter new password: Re-enter password:
NSS データベースがすでに存在する場合には、以下のようにパスワードが求められます。Enter Password or Pin for "NSS Certificate DB":
- 以下のコマンドを使用して、NSS データベースに永続的に証明書を追加します。
$ certutil -d sql:$HOME/.pki/nssdb -A -t TC -n "Red Hat Satellite" \ -i katello-server-ca.crt
これにより、証明書が NSS データベースにインポートされます。つまり、要求ごとに the-cacert
オプションを省略できます。これは、次のようにテストできます。$ curl -X GET -u sat_username:sat_password https://satellite6.example.com/api/v2/hosts { "total": 2, ..., "results": [ ... ] } output omitted
3.2. HTTP 認証の使用
Satellite API への要求にはすべて、適切なユーザー名とパスワードが必要です。API は HTTP Basic 認証を使用します。 [1] これらのクレデンシャルをエンコードするには、それが Authorization ヘッダーに追加されます。要求に適切な Authorization ヘッダーが含まれていない場合には、API は 401 Authorization Required エラーを返します。
重要
Basic 認証では、パスワードなどの機密情報がプレーンテキストで送信される可能性があります。REST API には、プレーンテキストの要求をトランスポートレベルで暗号化する HTTPS が必要です。
base64 ライブラリーによっては、暗号化された認証情報を複数行に分け、行末には改行文字を付けることがあります。そのような場合には、ヘッダーが破損し、要求に問題が発生します。認証ヘッダーには、エンコードされた認証情報がヘッダー内に一行で記載されている必要があります。
3.3. OAuth 認証の使用
Basic 認証の代わりに、制約はありますが API で OAuth 1.0 認証をサポートしています (プロトコルのバージョン 1.0a の 1-legged OAuth と呼ばれることもあります)。
3.3.1. OAuth の認証
Satellite 6.2 では、OAuth がデフォルトで有効になっています。設定は に移動して Web UI で確認できます。 は全 OAuth クライアントが使用するトークンです。Web UI の特定の値は変更できません。これらの値は、新しいオプションで satellite-installer スクリプトを再度実行することによってのみ変更できます。アップグレード時に、ファイルを手動で変更すると変更が失われることに注意してください。以下のコマンドを入力して、OAuth 関連のインストーラーオプションをすべて表示します。
/etc/foreman/settings.yaml
設定ファイルに保存され、 # satellite-installer --full-help | grep oauth
OAuth を使用して行われたすべての API リクエストを組み込みの匿名 API 管理者アカウントとして承認する場合は、
/etc/foreman/settings.yaml
ファイルで を false
に設定したままにします。リクエストを行うユーザーを指定する場合は、この設定オプションを true
に変更します。これにより、クライアントは既存の Foreman ユーザーのログインを含む FOREMAN-USER ヘッダーを送信できます。
重要
ヘッダーは OAuth 要求で署名されないため、偽造される可能性があります。有効なコンシューマーキーを持つユーザーなら誰でも、Foreman ユーザーになりすますことができます。
3.3.2. OAuth 要求の作成
通常、OAuth クライアントライブラリーは要求の生成に使用されます。curl を使用した OAuth 要求の例は、こちらでどのように機能するかを理解するのに役立ちます。
例3.1 curl を使用した OAuth 要求の例
$ curl 'https://satellite6.example.com/api/architectures' \ -H 'Content-Type: application/json' \ -H 'Accept: application/json,version=2' \ -H 'FOREMAN-USER: User1' \ -H 'Authorization: OAuth oauth_version="1.0",oauth_consumer_key="secretkey",oauth_signature_method="hmac-sha1",oauth_timestamp=1321473112,oauth_signature=Il8hR8/ogj/XVuOqMPB9qNjSy6E='上記の例では、認証に OAuth を使用してリストされています。ログイン User1 を持つユーザーとして要求を試みます。Foreman 設定でマッピングが有効になっている場合、結果には、ユーザー User1 が確認できるアーキテクチャーのみが含まれます。署名は手動で構築されたことに注意してください。これは
oauth_timestamp
の変更で変更する必要がある点に注意してください。また、署名にはすべてのパラメーター、HTTP メソッド、および URI の変更を反映します。そのため、OAuth クライアントライブラリーを使用してすべての OAuth パラメーターを構築することが推奨されます。