第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)。
  1. 以下のオプションのいずれかを使用して、通信する Satellite Server (satellite6.example.com)から証明書を取得します。
    1. SSH を使用して証明書を取得するには、以下のコマンドを実行します。
      $ scp root@satellite6.example.com:/var/www/html/pub/katello-server-ca.crt ./
    2. コマンドを Satellite Server で直接実行する場合は、以下のコマンドを実行してローカルで利用可能なコピーから証明書を取得します。
      $ cp /var/www/html/pub/katello-server-ca.crt ./
    3. HTTP を使用して証明書を取得するには、以下のコマンドを実行します。
      $ curl -O http://satellite6.example.com/pub/katello-server-ca.crt
      警告
      暗号化されていない HTTP 接続を使用して証明書を取得すると、セキュリティーリスクにさらされる可能性があります。
  2. クライアント上の証明書を認証局として使用して、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 属性を省略することができます。
  3. 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":
  4. 以下のコマンドを使用して、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 がデフォルトで有効になっています。設定は /etc/foreman/settings.yaml 設定ファイルに保存され、Administer Settings Auth に移動して Web UI で確認できます。OAuth コンシューマーキー は全 OAuth クライアントが使用するトークンです。Web UI の特定の値は変更できません。これらの値は、新しいオプションで satellite-installer スクリプトを再度実行することによってのみ変更できます。アップグレード時に、ファイルを手動で変更すると変更が失われることに注意してください。以下のコマンドを入力して、OAuth 関連のインストーラーオプションをすべて表示します。
# satellite-installer --full-help | grep oauth
OAuth を使用して行われたすべての API リクエストを組み込みの匿名 API 管理者アカウントとして承認する場合は、/etc/foreman/settings.yaml ファイルで OAuth マップユーザー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 パラメーターを構築することが推奨されます。


[1] Basic 認証については、RFC 2617 HTTP Authentication: Basic and Digest Access Authentication で説明されています。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.