認証

Azure Red Hat OpenShift 4

ユーザー認証、暗号化、およびユーザーとサービスのアクセス制御の設定

Red Hat OpenShift Documentation Team

概要

本書では、Azure Red Hat OpenShift 4 でアイデンティティープロバイダーを定義する方法を説明します。また、暗号化およびロールベースのアクセス制御を使ってクラスターのセキュリティーを保護する方法についても説明します。

第1章 認証について

ユーザーが Azure Red Hat OpenShift と対話できるようにするには、まずクラスターに対して認証する必要があります。認証層は、Azure Red Hat OpenShift API への要求に関連付けられたユーザーを識別します。その後、認可層は要求側ユーザーの情報を使用して、要求が許可されるかどうかを決定します。

1.1. ユーザー

Azure Red Hat OpenShift の ユーザー は、Azure Red Hat OpenShift API への要求を実行できるエンティティーです。Azure Red Hat OpenShift ユーザーオブジェクトは、それらおよびそれらのグループにロールを追加してシステム内のパーミッションを付与できるアクターを表します。通常、これは Azure Red Hat OpenShift と対話している開発者または管理者のアカウントを表します。

ユーザーにはいくつかのタイプが存在します。

regular user (通常ユーザー)

これは、大半の対話型の Azure Red Hat OpenShift ユーザーが表示される方法です。通常ユーザーは、初回ログイン時にシステムに自動的に作成され、API で作成できます。通常ユーザーは、 User オブジェクトで表示されます。例: joe alice

system user (システムユーザー)

これらの多くは、インフラストラクチャーが API と安全に対話できるようにすることを主な目的として定義される際に自動的に作成されます。これらには、クラスター管理者 (すべてのものへのアクセスを持つ)、ノードごとのユーザー、ルーターおよびレジストリーで使用できるユーザー、その他が含まれます。最後に、非認証要求に対してデフォルトで使用される anonymous (匿名) システムユーザーもあります。例: system:admin system:openshift-registry system:node:node1.example.com

service account (サービスアカウント)

プロジェクトに関連付けられる特殊なシステムユーザーがあります。それらの中には、プロジェクトの初回作成時に自動作成されるものもあれば、プロジェクト管理者が各プロジェクトのコンテンツへのアクセスを定義するために追加で作成するものもあります。サービスアカウントは ServiceAccount オブジェクトで表されます。例: system:serviceaccount:default:deployer system:serviceaccount:foo:builder

それぞれのユーザーには、Azure Red Hat OpenShift にアクセスするために何らかの認証が必要になります。認証がないか、認証が無効の API 要求は、anonymous (匿名) システムユーザーによる要求として認証されます。認証が実行されると、認可されているユーザーの実行内容がポリシーによって決定されます。

1.2. グループ

ユーザーは 1 つ以上の グループ に割り当てることができます。それぞれのグループはユーザーの特定のセットを表します。グループは、認可ポリシーを管理し、個々のユーザーにではなく、一度に複数ユーザーにパーミッションを付与する場合などに役立ちます。 たとえば、アクセスをユーザーに個別に付与するのではなく、プロジェクト内の複数のオブジェクトに対するアクセスを許可できます。

明示的に定義されるグループのほかにも、システムグループまたは 仮想グループ がクラスターによって自動的にプロビジョニングされます。

以下のデフォルト仮想グループは最も重要なグループになります。

仮想グループ説明

system:authenticated

認証されたユーザーに自動的に関連付けられます。

system:authenticated:oauth

OAuth アクセストークンで認証されたすべてのユーザーに自動的に関連付けられます。

system:unauthenticated

認証されていないすべてのユーザーに自動的に関連付けられます。

1.3. API 認証

Azure Red Hat OpenShift API への要求は以下の方法で認証されます。

OAuth アクセストークン
  • <namespace_route>/oauth/authorize および <namespace_route>/oauth/token エンドポイントを使用して Azure Red Hat OpenShift OAuth サーバーから取得されます。
  • Authorization: Bearer…​ ヘッダーとして送信されます。
  • websocket 要求の base64url.bearer.authorization.k8s.io.<base64url-encoded-token> 形式の websocket サブプロトコルヘッダーとして送信されます。
X.509 クライアント証明書
  • API サーバーへの HTTPS 接続を要求します。
  • 信頼される認証局バンドルに対して API サーバーによって検証されます。
  • API サーバーは証明書を作成し、これをコントローラーに配布してそれらを認証できるようにします。

無効なアクセストークンまたは無効な証明書での要求は認証層によって拒否され、401 エラーが出されます。

アクセストークンまたは証明証が提供されない場合、認証層は system:anonymous 仮想ユーザーおよび system:unauthenticated 仮想グループを要求に割り当てます。これにより、認可層は匿名ユーザーが実行できる要求 (ある場合) を決定できます。

1.3.1. Azure Red Hat OpenShift OAuth サーバー

Azure Red Hat OpenShift マスターには、ビルトイン OAuth サーバーが含まれます。ユーザーは OAuth アクセストークンを取得して、API に対して認証します。

新しいOAuthのトークンが要求されると、OAuth サーバーは設定済みのアイデンティティプロバイダーを使用して要求したユーザーのアイデンティティーを判別します。

次に、そのアイデンティティーがマップするユーザーを判別し、そのユーザーのアクセストークンを作成し、そのトークンを使用できるように返します。

1.3.1.1. OAuth トークン要求

OAuth トークンのすべての要求は、トークンを受信し、使用する OAuth クライアントを指定する必要があります。以下の OAuth クライアントは、Azure Red Hat OpenShift API の起動時に自動的に作成されます。

OAuth クライアント使用法

openshift-browser-client

対話式ログインを処理できるユーザーエージェントで <namespace_route>/oauth/token/request でトークンを要求します。

openshift-challenging-client

WWW-Authenticate チャレンジを処理できるユーザーエージェントでトークンを要求します。

注記

<namespace_route> は namespace のルートを参照します。これは、以下のコマンドを実行して確認できます。

oc get route oauth-openshift -n openshift-authentication -o json | jq .spec.host

OAuth トークンのすべての要求には <namespace_route>/oauth/authorize への要求が必要になります。ほとんどの認証統合では、認証プロキシーをこのエンドポイントの前に配置するか、または Azure Red Hat OpenShift を、サポートするアイデンティティープロバイダーに対して認証情報を検証するように設定します。<namespace_route>/oauth/authorize の要求は、CLI などの対話式ログインページを表示できないユーザーエージェントから送られる場合があります。そのため、Azure Red Hat OpenShift は、対話式ログインフローのほかにも WWW-Authenticate チャレンジを使用した認証をサポートします。

認証プロキシーが <namespace_route>/oauth/authorize エンドポイントの前に配置される場合、対話式ログインページを表示したり、対話式ログインフローにリダイレクトする代わりに、認証されていない、ブラウザー以外のユーザーエージェントの WWW-Authenticate チャレンジを送信します。

注記

ブラウザークライアントに対するクロスサイトリクエストフォージェリー (CSRF) 攻撃を防止するため、基本的な認証チャレンジは X-CSRF-Token ヘッダーが要求に存在する場合にのみ送信されます。基本的な WWW-Authenticate チャレンジを受信する必要があるクライアントでは、このヘッダーを空でない値に設定する必要があります。

認証プロキシーが WWW-Authenticate チャレンジをサポートしないか、または Azure Red Hat OpenShift が WWW-Authenticate チャレンジをサポートしないアイデンティティープロバイダーを使用するように設定されている場合、ユーザーはブラウザーで <namespace_route>/oauth/token/request からトークンを手動で取得する必要があります。

第2章 内部 OAuth サーバーの設定

重要

以下のオプションはマスター設定ファイルに設定されているため、それらの設定によって変更が生じます。

2.1. Azure Red Hat OpenShift OAuth サーバー

Azure Red Hat OpenShift マスターには、ビルトイン OAuth サーバーが含まれます。ユーザーは OAuth アクセストークンを取得して、API に対して認証します。

新しいOAuthのトークンが要求されると、OAuth サーバーは設定済みのアイデンティティプロバイダーを使用して要求したユーザーのアイデンティティーを判別します。

次に、そのアイデンティティーがマップするユーザーを判別し、そのユーザーのアクセストークンを作成し、そのトークンを使用できるように返します。

2.2. OAuth トークン要求フローおよび応答

OAuth サーバーは、標準的な Authorization Code Grant (認可コードによるグラント) および Implicit Grant (暗黙的グラント) の OAuth 認証フローをサポートします。

OAuth トークンを、 (openshift-challenging-client などの) WWW-Authenticate チャレンジ を要求するように設定された client_id で Implicit Grant (暗黙的グラント) フロー (response_type=token) を使用して要求する場合、以下が /oauth/authorize から送られる可能性のあるサーバー応答、およびそれらの処理方法になります。

ステータス音声内容クライアント応答

302

URL フラグメントに access_token パラメーターを含むLocation ヘッダー (RFC 4.2.2)

access_token 値を OAuth トークンとして使用します。

302

error クエリーパラメーターを含むLocation ヘッダー (RFC 4.1.2.1)

失敗します。 オプションで error (およびオプションの error_description) クエリー値をユーザーに表示します。

302

他の Location ヘッダー

これらのルールを使用してリダイレクトに従い、結果を処理します。

401

WWW-Authenticate ヘッダーが存在する

タイプ (BasicNegotiate など) が認識される場合にチャレンジに応答し、これらのルールを使用して要求を再送信し、結果を処理します。

401

WWW-Authenticate ヘッダーがない

チャレンジの承認ができません。失敗し、応答本体を表示します (これには、OAuth トークンを取得する別の方法についてのリンクまたは詳細が含まれる可能性があります)

その他

その他

失敗し、オプションでユーザーに応答本体を提示します。

2.3. 内部 OAuth サーバーのオプション

内部 OAuthサーバーには、いくつかの設定オプションを使用できます。

2.3.1. OAuth トークン期間のオプション

内部 OAuth サーバーは以下の 2 種類のトークンを生成します。

アクセストークン

API へのアクセスを付与する永続的なトークン。

認証コード

アクセストークンの交換にのみ使われる一時的なトークン。

どちらの種類のトークンにもデフォルト期間を設定できます。必要な場合は、OAuthClient オブジェクト定義を使用してアクセストークンの期間を上書きできます。

2.3.2. OAuth 付与オプション

OAuth サーバーが、ユーザーが以前にパーミッションを付与していないクライアントに対するトークン要求を受信する場合、OAuth サーバーが実行するアクションは OAuth クライアントの付与ストラテジーによって変わります。

トークンを要求する OAuth クライアントは、独自の付与ストラテジーを提供する必要があります。

以下のデフォルトの方法を使用できます。

auto

付与を自動承認し、要求を再試行します。

prompt

ユーザーに対して付与の承認または拒否を求めるプロンプトを出します。

2.4. 内部 OAuth サーバーのトークン期間の設定

内部 OAuth サーバーのトークン期間についてのデフォルトオプションを設定できます。

重要

デフォルトで、トークンは 24 時間有効になります。24 時間を経過すると、既存のセッションは期限切れになります。

デフォルトの時間では十分ではない場合、以下の手順でこれを変更することができます。

手順

  1. トークン期間オプションを含む設定ファイルを作成します。以下のファイルでは、これを、デフォルト値の 2 倍の 48 時間に設定しています。

    apiVersion: config.openshift.io/v1
    kind: OAuth
    metadata:
      name: cluster
    spec:
      tokenConfig:
        accessTokenMaxAgeSeconds: 172800 1
    1
    accessTokenMaxAgeSeconds を設定して、アクセストークンの有効期間を制御します。デフォルトの期間は 24 時間または 86400 秒です。この属性を負の値にすることはできません。
  2. 新規設定ファイルを適用します。

    注記

    既存の OAuth サーバーを更新するため、oc apply コマンドを使用して変更を適用する必要があります。

    $ oc apply -f </path/to/file.yaml>
  3. 変更が有効になっていることを確認します。

    $ oc describe oauth.config.openshift.io/cluster
    ...
    Spec:
      Token Config:
        Access Token Max Age Seconds:  172800
    ...

2.5. 追加の OAuthクライアントの登録

Azure Red Hat OpenShift クラスターの認証を管理するために追加の OAuth クライアントが必要になる場合は、これを登録することができます。

手順

  • 追加の OAuth クライアントを登録するには、以下を実行します。

    $ oc create -f <(echo '
    kind: OAuthClient
    apiVersion: oauth.openshift.io/v1
    metadata:
     name: demo 1
    secret: "..." 2
    redirectURIs:
     - "http://www.example.com/" 3
    grantMethod: prompt 4
    ')
    1
    OAuth クライアントの name は、<namespace_route>/oauth/authorize および <namespace_route>/oauth/token への要求を実行する際に client_id パラメーターとして使用されます。
    2
    secret は、<namespace_route>/oauth/token への要求の実行時に client_secret パラメーターとして使用されます。
    3
    <namespace_route>/oauth/authorize および <namespace_route>/oauth/token への要求で指定される redirect_uri パラメーターは、redirectURIs パラメーター値に一覧表示されるいずれかの URI と等しいか、またはこれによってプレフィックスが付けられている必要があります。
    4
    grantMethod は、このクライアントがトークンを要求するものの、ユーザーによってアクセスが付与されていない場合に実行するアクションを判別するために使用されます。付与を自動的に承認し、要求を再試行するには auto を指定し、ユーザーに対して付与の承認または付与を求めるプロンプトを出す場合には prompt を指定します。

2.6. OAuth サーバーメタデータ

Azure Red Hat OpenShift で実行されているアプリケーションは、ビルトイン OAuth サーバーについての情報を検出する必要がある場合があります。たとえば、それらは <namespace_route> のアドレスを手動の設定なしで検出する必要があります。これを支援するために、Azure Red Hat OpenShift は IETF OAuth 2.0 Authorization Server Metadata ドラフト仕様を実装しています。

そのため、クラスター内で実行されているすべてのアプリケーションは、https://openshift.default.svc/.well-known/oauth-authorization-server に対して GET 要求を実行し、以下の情報を取得できます。

{
  "issuer": "https://<namespace_route>", 1
  "authorization_endpoint": "https://<namespace_route>/oauth/authorize", 2
  "token_endpoint": "https://<namespace_route>/oauth/token", 3
  "scopes_supported": [ 4
    "user:full",
    "user:info",
    "user:check-access",
    "user:list-scoped-projects",
    "user:list-projects"
  ],
  "response_types_supported": [ 5
    "code",
    "token"
  ],
  "grant_types_supported": [ 6
    "authorization_code",
    "implicit"
  ],
  "code_challenge_methods_supported": [ 7
    "plain",
    "S256"
  ]
}
1
https スキームを使用し、クエリーまたはフラグメントコンポーネントがない認可サーバーの発行者 IDです。これは、認可サーバーについての情報が含まれる .well-known RFC 5785 リソースが公開される場所です。
2
認可サーバーの認可エンドポートの URL です。RFC 6749を参照してください。
3
認可サーバーのトークンエンドポイントの URL です。RFC 6749を参照してください。
4
この認可サーバーがサポートする OAuth 2.0 RFC 6749 スコープの値の一覧を含む JSON 配列です。サポートされるスコープの値すべてが公開される訳ではないことに注意してください。
5
この認可サーバーがサポートする OAuth 2.0 response_type 値の一覧を含む JSON 配列です。使用される配列の値は、RFC 7591 の OAuth 2.0 Dynamic Client Registration Protocol で定義される response_types パラメーターで使用されるものと同じです
6
この認可サーバーがサポートする OAuth 2.0 grant type の値の一覧が含まれる JSON 配列です。使用される配列の値は、RFC 7591 の OAuth 2.0 Dynamic Client Registration Protocol で定義される grant_types パラメーターで使用されるものと同じです
7
この認可サーバーでサポートされる PKCE RFC 7636 コードのチャレンジメソッドの一覧が含まれる JSON 配列です。コード のチャレンジメソッドの値は、RFC 7636 のセクション 4.3で定義される code_challenge_method パラメーターで使用されます。有効なコードのチャレンジメソッドの値は、IANA PKCE Code Challenge Methods レジストリーで登録される値です。「IANA OAuth パラメーター」を参照してください。

2.7. OAuth API イベントのトラブルシューティング

API サーバーは、API マスターログへの直接的なアクセスがないとデバッグが困難な unexpected condition のエラーメッセージを返すことがあります。このエラーの根本的な理由は意図的に非表示にされます。 認証されていないユーザーにサーバーの状態についての情報を提供することを避けるためです。

これらのエラーのサブセットは、サービスアカウントの OAuth 設定の問題に関連するものです。これらの問題は、管理者以外のユーザーが確認できるイベントでキャプチャーされます。unexpected condition というサーバーエラーが OAuth の実行時に発生する場合、oc get events を実行し、これらのイベントについて ServiceAccount で確認します。

以下の例では、適切な OAuth リダイレクト URI がないサービスアカウントに対して警告しています。

$ oc get events | grep ServiceAccount
1m         1m          1         proxy                    ServiceAccount                                  Warning   NoSAOAuthRedirectURIs   service-account-oauth-client-getter   system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>

oc describe sa/<service-account-name> を実行すると、指定のサービスアカウント名に関連付けられた OAuth イベントが報告されます。

$ oc describe sa/proxy | grep -A5 Events
Events:
  FirstSeen     LastSeen        Count   From                                    SubObjectPath   Type            Reason                  Message
  ---------     --------        -----   ----                                    -------------   --------        ------                  -------
  3m            3m              1       service-account-oauth-client-getter                     Warning         NoSAOAuthRedirectURIs   system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>

以下は生じる可能性のあるイベントエラーの一覧です。

リダイレクト URI アノテーションが指定されていないか、無効な URI が指定されている

Reason                  Message
NoSAOAuthRedirectURIs   system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>

無効なルートが指定されている

Reason                  Message
NoSAOAuthRedirectURIs   [routes.route.openshift.io "<name>" not found, system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]

無効な参照タイプが指定されている

Reason                  Message
NoSAOAuthRedirectURIs   [no kind "<name>" is registered for version "v1", system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]

SA トークンがない

Reason                  Message
NoSAOAuthTokens         system:serviceaccount:myproject:proxy has no tokens

第3章 アイデンティティープロバイダー設定について

Azure Red Hat OpenShift マスターには、ビルトイン OAuth サーバーが含まれます。開発者および管理者は OAuth アクセストークンを取得して、API に対して認証します。

管理者は、クラスターのインストール後に、OAuth をアイデンティティープロバイダーを指定するように設定できます。

3.1. Azure Red Hat OpenShift のアイデンティティープロバイダーについて

デフォルトでは、kubeadmin ユーザーのみがクラスターに存在します。アイデンティティープロバイダーを指定するには、アイデンティティープロバイダーを記述し、これをクラスターに追加するカスタムリソース (CR、Custom Resource) を作成する必要があります。

注記

/:、および % を含む Azure Red Hat OpenShift ユーザー名はサポートされません。

3.2. サポートされるアイデンティティープロバイダー

以下の種類のアイデンティティープロバイダーを設定できます。

アイデンティティープロバイダー説明

HTPasswd

htpasswd アイデンティティープロバイダーを htpasswdを使用して生成されたフラットファイルに対してユーザー名とパスワードを検証するように設定します。

Keystone

keystone アイデンティティープロバイダーを、Azure Red Hat OpenShift クラスターを Keystone に統合し、ユーザーを内部データベースに保存するように設定された OpenStack Keystone v3 サーバーによる共有認証を有効にするように設定します。

LDAP

ldap アイデンティティープロバイダーを、単純なバインド認証を使用して LDAPv3 サーバーに対してユーザー名とパスワードを検証するように設定します。

Basic 認証

basic-authentication アイデンティティープロバイダーを、ユーザーがリモートアイデンティティープロバイダーに対して検証された認証情報を使って Azure Red Hat OpenShift にログインできるように設定します。Basic 認証は、汎用的なバックエンド統合メカニズムです。

要求ヘッダー

request-header アイデンティティープロバイダーを、X-Remote-User などの要求ヘッダー値から識別するように設定します。通常、これは要求ヘッダー値を設定する認証プロキシーと併用されます。

GitHub または GitHub Enterprise

github アイデンティティープロバイダーを、GitHub または GitHub Enterprise の OAuth 認証サーバーに対してユーザー名とパスワードを検証するように設定します。

GitLab

gitlab アイデンティティープロバイダーを、GitLab.com またはその他の GitLab インスタンスをアイデンティティープロバイダーとして使用するように設定します。

Google

google アイデンティティープロバイダーを、Google の OpenID Connect 統合を使用して設定します。

OpenID Connect

oidc アイデンティティープロバイダーを、Authorization Code Flowを使用して OpenID Connect アイデンティティープロバイダーと統合するように設定します。

アイデンティティープロバイダーが定義された後に、RBAC を使用してパーミッションの定義および適用を実行できます。

3.3. kubeadmin ユーザーの削除

アイデンティティープロバイダーを定義し、新規 cluster-admin ユーザーを作成した後に、クラスターのセキュリティーを強化するために kubeadmin を削除できます。

警告

別のユーザーが cluster-admin になる前にこの手順を実行する場合、Azure Red Hat OpenShift は再インストールされる必要があります。このコマンドをやり直すことはできません。

前提条件

  • 1 つ以上のアイデンティティープロバイダーを設定しておく必要があります。
  • cluster-admin ロールをユーザーに追加しておく必要があります。
  • 管理者としてログインしている必要があります。

手順

  • kubeadmin シークレットを削除します。

    $ oc delete secrets kubeadmin -n kube-system

3.4. アイデンティティープロバイダーパラメーター

以下のパラメーターは、すべてのアイデンティティープロバイダーに共通するパラメーターです。

パラメーター説明

name

プロバイダー名は、プロバイダーのユーザー名にプレフィックスとして付加され、アイデンティティー名が作成されます。

mappingMethod

新規アイデンティティーがログイン時にユーザーにマップされる方法を定義します。以下の値のいずれかを入力します。

claim
デフォルトの値です。アイデンティティーの推奨ユーザー名を持つユーザーをプロビジョニングします。そのユーザー名を持つユーザーがすでに別のアイデンティティーにマッピングされている場合は失敗します。
lookup
既存のアイデンティティー、ユーザーアイデンティティーマッピング、およびユーザーを検索しますが、ユーザーまたはアイデンティティーの自動プロビジョニングは行いません。これにより、クラスター管理者は手動で、または外部のプロセスを使用してアイデンティティーとユーザーを設定できます。この方法を使用する場合は、ユーザーを手動でプロビジョニングする必要があります。
generate
アイデンティティーの推奨ユーザー名を持つユーザーをプロビジョニングします。推奨ユーザー名を持つユーザーがすでに既存のアイデンティティーにマッピングされている場合は、一意のユーザー名が生成されます。例: myuser2この方法は、Azure Red Hat OpenShift のユーザー名とアイデンティティープロバイダーのユーザー名との正確な一致を必要とする外部プロセス (LDAP グループ同期など) と組み合わせて使用することはできません。
add
アイデンティティーの推奨ユーザー名を持つユーザーをプロビジョニングします。推奨ユーザー名を持つユーザーがすでに存在する場合、アイデンティティーは既存のユーザーにマッピングされ、そのユーザーの既存のアイデンティティーマッピングに追加されます。これは、同じユーザーセットを識別して同じユーザー名にマッピングするアイデンティティープロバイダーが複数設定されている場合に必要です。
注記

mappingMethod パラメーターを add に設定すると、アイデンティティープロバイダーの追加または変更時に新規プロバイダーのアイデンティティーを既存ユーザーにマッピングできます。

3.5. アイデンティティープロバイダー CR のサンプル

以下のカスタムリソース (CR) は、アイデンティティープロバイダーを設定するために使用するパラメーターおよびデフォルト値を示します。この例では、HTPasswd アイデンティティープロバイダーを使用しています。

アイデンティティープロバイダー CR のサンプル

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: my_identity_provider 1
    mappingMethod: claim 2
    type: HTPasswd
    htpasswd:
      fileData:
        name: htpass-secret 3

1
このプロバイダー名は、プロバイダーのユーザー名にプレフィックスとして付加され、アイデンティティー名が作成されます。
2
このプロバイダーのアイデンティティーとユーザーオブジェクト間にマッピングが確立される方法を制御します。
3
htpasswdを使用して生成されたファイルが含まれる既存のシークレットです。

第4章 アイデンティティープロバイダーの設定

4.1. HTPasswd アイデンティティープロバイダーの設定

4.1.1. Azure Red Hat OpenShift のアイデンティティープロバイダーについて

デフォルトでは、kubeadmin ユーザーのみがクラスターに存在します。アイデンティティープロバイダーを指定するには、アイデンティティープロバイダーを記述し、これをクラスターに追加するカスタムリソース (CR、Custom Resource) を作成する必要があります。

注記

/:、および % を含む Azure Red Hat OpenShift ユーザー名はサポートされません。

HTPasswd アイデンティティープロバイダーを定義するには、以下の手順を実行する必要があります。

  1. ユーザーおよびパスワード情報を保存するために htpasswd ファイルを作成します。Linux および Windows用の手順が説明されます。
  2. htpasswd ファイルを表すために Azure Red Hat OpenShift シークレットを作成します 。
  3. HTPasswd アイデンティティープロバイダーリソースを定義します
  4. リソースをデフォルトの OAuth 設定に適用します

4.1.2. Linux を使用した HTPasswd ファイルの作成

HTPasswd アイデンティティープロバイダーを使用するには、htpasswdを使用してクラスターのユーザー名およびパスワードを含むフラットファイルを生成する必要があります。

前提条件

  • htpasswd ユーティリティーへのアクセスがあること。Red Hat Enterprise Linux では、これは httpd-tools パッケージをインストールして利用できます。

手順

  1. ユーザー名およびハッシュされたパスワードを含むフラットファイルを作成します。

    $ htpasswd -c -B -b </path/to/users.htpasswd> <user_name> <password>

    コマンドにより、ハッシュされたバージョンのパスワードが生成されます。

    例:

    $ htpasswd -c -B -b users.htpasswd user1 MyPassword!
    
    Adding password for user user1
  2. ファイルに対する認証情報の追加またはその更新を継続します。

    $ htpasswd -B -b </path/to/users.htpasswd> <user_name> <password>

4.1.3. Windows を使用した HTPasswd ファイルの作成

HTPasswd アイデンティティープロバイダーを使用するには、htpasswdを使用してクラスターのユーザー名およびパスワードを含むフラットファイルを生成する必要があります。

前提条件

  • htpasswd.exe へのアクセスがあること。このファイルは、数多くの Apache httpd ディストリビューションの \bin ディレクトリーに含まれます。

手順

  1. ユーザー名およびハッシュされたパスワードを含むフラットファイルを作成します。

    > htpasswd.exe -c -B -b <\path\to\users.htpasswd> <user_name> <password>

    コマンドにより、ハッシュされたバージョンのパスワードが生成されます。

    例:

    > htpasswd.exe -c -B -b users.htpasswd user1 MyPassword!
    
    Adding password for user user1
  2. ファイルに対する認証情報の追加またはその更新を継続します。

    > htpasswd.exe -b <\path\to\users.htpasswd> <user_name> <password>

4.1.4. HTPasswd シークレットの作成

HTPasswd アイデンティティープロバイダーを使用するには、HTPasswd ユーザーファイルが含まれるシークレットを定義する必要があります。

前提条件

  • HTPasswd ファイルを作成します。

手順

  • HTPasswd ユーザーファイルが含まれる Azure Red Hat OpenShift シークレットを作成します。

    $ oc create secret generic htpass-secret --from-file=htpasswd=</path/to/users.htpasswd> -n openshift-config
    注記

    上記のコマンドが示すように、--from-file 引数についてのユーザーファイルを含むシークレットキーには htpasswd という名前を指定する必要があります。

4.1.5. HTPasswd CR のサンプル

以下のカスタムリソース (CR) は、HTPasswd アイデンティティープロバイダーのパラメーターおよび許可される値を示します。

HTPasswd CR

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: my_htpasswd_provider 1
    mappingMethod: claim 2
    type: HTPasswd
    htpasswd:
      fileData:
        name: htpass-secret 3

1
このプロバイダー名は、プロバイダーのユーザー名にプレフィックスとして付加され、アイデンティティー名が作成されます。
2
このプロバイダーのアイデンティティーとユーザーオブジェクト間にマッピングが確立される方法を制御します。
3
htpasswdを使用して生成されたファイルが含まれる既存のシークレットです。

4.1.6. アイデンティティープロバイダーのクラスターへの追加

クラスターのインストール後に、アイデンティティープロバイダーをそのクラスターに追加し、ユーザーの認証を実行できるようにします。

前提条件

  • Azure Red Hat OpenShift クラスターを作成します。
  • アイデンティティープロバイダーのカスタムリソース (CR) を作成します。
  • 管理者としてログインしている必要があります。

手順

  1. 定義された CR を適用します。

    $ oc apply -f </path/to/CR>
    注記

    CR が存在しない場合、oc apply は新規 CR を作成し、さらに以下の警告をトリガーする可能性があります。Warning: oc apply should be used on resources created by either oc create --save-config or oc applyこの場合は、この警告を無視しても問題ありません。

  2. アイデンティティープロバイダーのユーザーとしてクラスターにログインし、プロンプトが出されたらパスワードを入力します。

    $ oc login -u <username>
  3. ユーザーが正常にログインされていることを確認し、ユーザー名を表示します。

    $ oc whoami

4.1.7. HTPasswd アイデンティティープロバイダーの更新

既存の HTPasswd アイデンティティープロバイダーにユーザーを追加したり、既存の HTPasswd アイデンティティープロバイダーからユーザーを削除したりできます。

前提条件

  • HTPasswd ユーザーファイルが含まれるシークレットを作成している。この手順では、htpass-secret という名前であることを前提としています。
  • HTPasswd アイデンティティープロバイダーを設定している。この手順では、my_htpasswd_provider という名前であることを前提としています。
  • htpasswd ユーティリティーへのアクセスがある。Red Hat Enterprise Linux では、これは httpd-tools パッケージをインストールして利用できます。
  • クラスター管理者の権限がある。

手順

  1. HTPasswd ファイルを htpass-secret シークレットから取得し、ファイルをお使いのファイルシステムに保存します。

    $ oc get secret htpass-secret -ojsonpath={.data.htpasswd} -n openshift-config | base64 -d > users.htpasswd
  2. users.htpasswd ファイルからユーザーを追加したり、削除したりします。

    • 新規ユーザーを追加するには、以下を実行します。

      $ htpasswd -bB users.htpasswd <username> <password>
      Adding password for user <username>
    • 既存ユーザーを削除するには、以下を実行します。

      $ htpasswd -D users.htpasswd <username>
      Deleting password for user <username>
  3. htpass-secret シークレットを、users.htpasswd ファイルの更新されたユーザーに置き換えます。

    $ oc create secret generic htpass-secret --from-file=htpasswd=users.htpasswd --dry-run -o yaml -n openshift-config | oc replace -f -
  4. 複数のユーザーを削除した場合は、追加でユーザーごとに既存のリソースを削除する必要があります。

    1. ユーザーを削除します。

      $ oc delete user <username>
      user.user.openshift.io "<username>" deleted

      ユーザーを必ず削除してください。削除しない場合、ユーザーは期限切れでない限り、トークンを引き続き使用できます。

    2. ユーザーのアイデンティティーを削除します。

      $ oc delete identity my_htpasswd_provider:<username>
      identity.user.openshift.io "my_htpasswd_provider:<username>" deleted

4.1.8. Web コンソールを使用したアイデンティティープロバイダーの設定

CLI ではなく Web コンソールを使用してアイデンティティープロバイダー (IDP) を設定します。

前提条件

  • クラスター管理者として Web コンソールにログインしている必要があります。

手順

  1. AdministrationCluster Settings に移動します。
  2. Global Configuration タブで、OAuth をクリックします。
  3. Identity Providers セクションで、Add ドロップダウンメニューからアイデンティティープロバイダーを選択します。
注記

既存の IDP を上書きすることなく、Web コンソールで複数の IDP を指定することができます。

4.2. Keystone アイデンティティープロバイダーの設定

keystone アイデンティティープロバイダーを、Azure Red Hat OpenShift クラスターを Keystone に統合し、ユーザーを内部データベースに保存するように設定された OpenStack Keystone v3 サーバーによる共有認証を有効にするように設定します。この設定により、ユーザーは Keystone 認証情報を使って Azure Red Hat OpenShift にログインできます。

Keystone は、アイデンティティー、トークン、カタログ、およびポリシーサービスを提供する OpenStack プロジェクトです。

新規 Azure Red Hat OpenShift ユーザーが Keystone ユーザー名または一意の Keystone ID をベースに設定されるように Keystone との統合を設定できます。どちらの方法でも、ユーザーは Keystone ユーザー名およびパスワードを入力してログインします。Azure Red Hat OpenShift ユーザーのベースを Keystone ID としない方法がより安全な方法になります。Keystone ユーザーを削除し、そのユーザー名で新規の Keystone ユーザーを作成する場合、新規ユーザーが古いユーザーのリソースにアクセスできる可能性があるためです。

4.2.1. Azure Red Hat OpenShift のアイデンティティープロバイダーについて

デフォルトでは、kubeadmin ユーザーのみがクラスターに存在します。アイデンティティープロバイダーを指定するには、アイデンティティープロバイダーを記述し、これをクラスターに追加するカスタムリソース (CR、Custom Resource) を作成する必要があります。

注記

/:、および % を含む Azure Red Hat OpenShift ユーザー名はサポートされません。

4.2.2. シークレットの作成

アイデンティティープロバイダーは openshift-config namespace で Azure Red Hat OpenShift シークレットを使用して、クライアントシークレット、クライアント証明書およびキーをこれに組み込みます。

  • 以下のコマンドを使用して、Azure Red Hat OpenShift シークレットを定義できます。

    $ oc create secret generic <secret_name> --from-literal=clientSecret=<secret> -n openshift-config
  • 以下のコマンドを実行して、証明書ファイルなどのファイルの内容を含む Azure Red Hat OpenShift シークレットを定義できます。

    $ oc create secret generic <secret_name> --from-file=/path/to/file -n openshift-config

4.2.3. ConfigMap の作成

アイデンティティープロバイダーは、openshift-config namespace で Azure Red Hat OpenShift ConfigMap を使用し、認証局バンドルをこれに組み込みます。これらは、主にアイデンティティープロバイダーで必要な証明書バンドルを組み込むために使用されます。

  • 以下のコマンドを使用して、認証局が含まれる Azure Red Hat OpenShift ConfigMap を定義します。認証局は ConfigMap の ca.crt キーに保存する必要があります。

    $ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config

4.2.4. Keystone CR のサンプル

以下のカスタムリソース (CR) は、Keystone アイデンティティープロバイダーのパラメーターおよび許可される値を示します。

Keystone CR

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: keystoneidp 1
    mappingMethod: claim 2
    type: Keystone
    keystone:
      domainName: default 3
      url: https://keystone.example.com:5000 4
      ca: 5
        name: ca-config-map
      tlsClientCert: 6
        name: client-cert-secret
      tlsClientKey: 7
        name: client-key-secret

1
このプロバイダー名は、プロバイダーのユーザー名にプレフィックスとして付加され、アイデンティティー名が作成されます。
2
このプロバイダーのアイデンティティーとユーザーオブジェクト間にマッピングが確立される方法を制御します。
3
Keystone のドメイン名です。Keystone では、ユーザー名はドメインに固有の名前です。単一ドメインのみがサポートされます。
4
Keystone サーバーへの接続に使用する URL です (必須) 。https を使用する必要があります。
5
オプション: 設定済みの URL のサーバー証明書を検証するために使用する PEM エンコードされた認証局バンドルを含む Azure Red Hat OpenShift ConfigMap への参照。
6
オプション: 設定済み URL への要求を実行する際に存在させるクライアント証明書を含む Azure Red Hat OpenShift シークレットへの参照。
7
クライアント証明書のキーを含む Azure Red Hat OpenShift シークレットへの参照。tlsClientCert が指定されている場合には必須になります。

4.2.5. アイデンティティープロバイダーのクラスターへの追加

クラスターのインストール後に、アイデンティティープロバイダーをそのクラスターに追加し、ユーザーの認証を実行できるようにします。

前提条件

  • Azure Red Hat OpenShift クラスターを作成します。
  • アイデンティティープロバイダーのカスタムリソース (CR) を作成します。
  • 管理者としてログインしている必要があります。

手順

  1. 定義された CR を適用します。

    $ oc apply -f </path/to/CR>
    注記

    CR が存在しない場合、oc apply は新規 CR を作成し、さらに以下の警告をトリガーする可能性があります。Warning: oc apply should be used on resources created by either oc create --save-config or oc applyこの場合は、この警告を無視しても問題ありません。

  2. アイデンティティープロバイダーのユーザーとしてクラスターにログインし、プロンプトが出されたらパスワードを入力します。

    $ oc login -u <username>
  3. ユーザーが正常にログインされていることを確認し、ユーザー名を表示します。

    $ oc whoami

4.3. LDAP アイデンティティープロバイダーの設定

ldap アイデンティティープロバイダーを、単純なバインド認証を使用して LDAPv3 サーバーに対してユーザー名とパスワードを検証するように設定します。

4.3.1. LDAP 認証について

認証時に、指定されたユーザー名に一致するエントリーが LDAP ディレクトリーで検索されます。単一の一意の一致が見つかった場合、エントリーの識別名 (DN) と指定されたパスワードを使用した単純なバインドが試みられます。

以下の手順が実行されます。

  1. 設定された url の属性およびフィルターとユーザーが指定したユーザー名を組み合わせて検索フィルターを生成します。
  2. 生成されたフィルターを使用してディレクトリーを検索します。検索によって 1 つもエントリーが返されない場合は、アクセスを拒否します。
  3. 検索で取得したエントリーの DN とユーザー指定のパスワードを使用して LDAP サーバーへのバインドを試みます。
  4. バインドが失敗した場合は、アクセスを拒否します。
  5. バインドが成功した場合は、アイデンティティー、電子メールアドレス、表示名、および推奨ユーザー名として設定された属性を使用してアイデンティティーを作成します。

設定される url は、LDAP ホストと使用する検索パラメーターを指定する RFC 2255 URL です。URL の構文は以下のようになります。

ldap://host:port/basedn?attribute?scope?filter

この URL の場合:

URL コンポーネント説明

ldap

通常の LDAP の場合は、文字列 ldap を使用します。セキュアな LDAP (LDAPS) の場合は、代わりに ldaps を使用します。

host:port

LDAP サーバーの名前とポートです。デフォルトは、ldap の場合は localhost:389、LDAPS の場合は localhost:636 です。

basedn

すべての検索が開始されるディレクトリーのブランチの DN です。これは少なくともディレクトリーツリーの最上位になければなりませんが、ディレクトリーのサブツリーを指定することもできます。

attribute

検索対象の属性です。RFC 2255 はカンマ区切りの属性の一覧を許可しますが、属性をどれだけ指定しても最初の属性のみが使用されます。属性を指定しない場合は、デフォルトで uid が使用されます。使用しているサブツリーのすべてのエントリー間で一意の属性を選択することを推奨します。

scope

検索の範囲です。one または sub のいずれかを指定できます。範囲を指定しない場合は、デフォルトの範囲として sub が使用されます。

filter

有効な LDAP 検索フィルターです。指定しない場合、デフォルトは (objectClass=*) です。

検索の実行時に属性、フィルター、指定したユーザー名が組み合わされて以下のような検索フィルターが作成されます。

(&(<filter>)(<attribute>=<username>))

たとえば、以下の URL について見てみましょう。

ldap://ldap.example.com/o=Acme?cn?sub?(enabled=true)

クライアントが bob というユーザー名を使用して接続を試みる場合、生成される検索フィルターは (&(enabled=true)(cn=bob)) になります。

LDAP ディレクトリーの検索に認証が必要な場合は、エントリー検索の実行に使用する bindDNbindPassword を指定します。

4.4. Basic 認証アイデンティティープロバイダーの設定

basic-authentication アイデンティティープロバイダーを、ユーザーがリモートアイデンティティープロバイダーに対して検証された認証情報を使って Azure Red Hat OpenShift にログインできるように設定します。Basic 認証は、汎用的なバックエンド統合メカニズムです。

4.4.1. Azure Red Hat OpenShift のアイデンティティープロバイダーについて

デフォルトでは、kubeadmin ユーザーのみがクラスターに存在します。アイデンティティープロバイダーを指定するには、アイデンティティープロバイダーを記述し、これをクラスターに追加するカスタムリソース (CR、Custom Resource) を作成する必要があります。

注記

/:、および % を含む Azure Red Hat OpenShift ユーザー名はサポートされません。

4.4.2. Basic 認証について

Basic 認証は、ユーザーがリモートのアイデンティティープロバイダーに対して検証した認証情報を使用して Azure Red Hat OpenShift にログインすることを可能にする汎用バックエンド統合メカニズムです。

Basic 認証は汎用性があるため、このアイデンティティープロバイダー使用して詳細な認証設定を実行できます。

注意

Basic 認証では、ユーザー ID とパスワードのスヌーピングを防ぎ、中間者攻撃を回避するためにリモートサーバーへの HTTPS 接続を使用する必要があります。

Basic 認証が設定されると、ユーザーはユーザー名とパスワードを Azure Red Hat OpenShift に送信し、サーバー間の要求を行い、認証情報を Basic 認証ヘッダーとして渡すことで、これらの認証情報をリモートサーバーに対して検証することができます。このため、ユーザーはログイン時に認証情報を Azure Red Hat OpenShift に送信する必要があります。

注記

これはユーザー名/パスワードログインの仕組みにのみ有効で、Azure Red Hat OpenShift はリモート認証サーバーに対するネットワーク要求を実行できる必要があります。

ユーザー名およびパスワードは Basic 認証で保護されるリモート URL に対して検証され、JSON が返されます。

401 応答は認証の失敗を示しています。

200 以外のステータスまたは空でない「エラー」キーはエラーを示しています。

{"error":"Error message"}

sub (サブジェクト) キーを持つ 200 ステータスは、成功を示しています。

{"sub":"userid"} 1
1
このサブジェクトは認証ユーザーに固有である必要があり、変更することができません。

正常な応答により、以下のような追加データがオプションで提供されることがあります。

  • name キーを使用した表示名。例:

    {"sub":"userid", "name": "User Name", ...}
  • email キーを使用したメールアドレス。例:

    {"sub":"userid", "email":"user@example.com", ...}
  • preferred_username キーを使用した推奨ユーザー名。これは、固有の変更できないサブジェクトがデータベースキーまたは UID であり、判読可能な名前が存在する場合に便利です。これは、認証されたアイデンティティーの Azure Red Hat OpenShift ユーザーをプロビジョニングする場合にヒントとして使われます。以下は例になります。

    {"sub":"014fbff9a07c", "preferred_username":"bob", ...}

4.4.3. シークレットの作成

アイデンティティープロバイダーは openshift-config namespace で Azure Red Hat OpenShift シークレットを使用して、クライアントシークレット、クライアント証明書およびキーをこれに組み込みます。

  • 以下のコマンドを使用して、Azure Red Hat OpenShift シークレットを定義できます。

    $ oc create secret generic <secret_name> --from-literal=clientSecret=<secret> -n openshift-config
  • 以下のコマンドを実行して、証明書ファイルなどのファイルの内容を含む Azure Red Hat OpenShift シークレットを定義できます。

    $ oc create secret generic <secret_name> --from-file=/path/to/file -n openshift-config

4.4.4. ConfigMap の作成

アイデンティティープロバイダーは、openshift-config namespace で Azure Red Hat OpenShift ConfigMap を使用し、認証局バンドルをこれに組み込みます。これらは、主にアイデンティティープロバイダーで必要な証明書バンドルを組み込むために使用されます。

  • 以下のコマンドを使用して、認証局が含まれる Azure Red Hat OpenShift ConfigMap を定義します。認証局は ConfigMap の ca.crt キーに保存する必要があります。

    $ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config

4.4.5. Basic 認証 CR のサンプル

以下のカスタムリソース (CR) は、Basic 認証アイデンティティープロバイダーのパラメーターおよび許可される値を示します。

Basic 認証 CR

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: basicidp 1
    mappingMethod: claim 2
    type: BasicAuth
    basicAuth:
      url: https://www.example.com/remote-idp 3
      ca: 4
        name: ca-config-map
      tlsClientCert: 5
        name: client-cert-secret
      tlsClientKey: 6
        name: client-key-secret

1
このプロバイダー名は返されるユーザー名にプレフィックスとして付加され、アイデンティティー名が作成されます。
2
このプロバイダーのアイデンティティーとユーザーオブジェクト間にマッピングが確立される方法を制御します。
3
Basic 認証ヘッダーで認証情報を受け入れる URL。
4
オプション: 設定済みの URL のサーバー証明書を検証するために使用する PEM エンコードされた認証局バンドルを含む Azure Red Hat OpenShift ConfigMap への参照。
5
オプション: 設定済み URL への要求を実行する際に存在させるクライアント証明書を含む Azure Red Hat OpenShift シークレットへの参照。
6
クライアント証明書のキーを含む Azure Red Hat OpenShift シークレットへの参照。tlsClientCert が指定されている場合には必須になります。

4.4.6. アイデンティティープロバイダーのクラスターへの追加

クラスターのインストール後に、アイデンティティープロバイダーをそのクラスターに追加し、ユーザーの認証を実行できるようにします。

前提条件

  • Azure Red Hat OpenShift クラスターを作成します。
  • アイデンティティープロバイダーのカスタムリソース (CR) を作成します。
  • 管理者としてログインしている必要があります。

手順

  1. 定義された CR を適用します。

    $ oc apply -f </path/to/CR>
    注記

    CR が存在しない場合、oc apply は新規 CR を作成し、さらに以下の警告をトリガーする可能性があります。Warning: oc apply should be used on resources created by either oc create --save-config or oc applyこの場合は、この警告を無視しても問題ありません。

  2. アイデンティティープロバイダーのユーザーとしてクラスターにログインし、プロンプトが出されたらパスワードを入力します。

    $ oc login -u <username>
  3. ユーザーが正常にログインされていることを確認し、ユーザー名を表示します。

    $ oc whoami

4.4.7. 基本的なアイデンティティープロバイダーの Apache HTTPD 設定の例

Azure Red Hat OpenShift 4 の基本的なアイデンティティープロバイダー (IDP) 設定では、IDP サーバーが成功および失敗について JSON で応答する必要があります。これを可能にするために、Apache HTTPD で CGI スクリプトを使用できます。本セクションでは、いくつかの例を紹介します。

/etc/httpd/conf.d/login.conf

<VirtualHost *:443>
  # CGI Scripts in here
  DocumentRoot /var/www/cgi-bin

  # SSL Directives
  SSLEngine on
  SSLCipherSuite PROFILE=SYSTEM
  SSLProxyCipherSuite PROFILE=SYSTEM
  SSLCertificateFile /etc/pki/tls/certs/localhost.crt
  SSLCertificateKeyFile /etc/pki/tls/private/localhost.key

  # Configure HTTPD to execute scripts
  ScriptAlias /basic /var/www/cgi-bin

  # Handles a failed login attempt
  ErrorDocument 401 /basic/fail.cgi

  # Handles authentication
  <Location /basic/login.cgi>
    AuthType Basic
    AuthName "Please Log In"
    AuthBasicProvider file
    AuthUserFile /etc/httpd/conf/passwords
    Require valid-user
  </Location>
</VirtualHost>

/var/www/cgi-bin/login.cgi

#!/bin/bash
echo "Content-Type: application/json"
echo ""
echo '{"sub":"userid", "name":"'$REMOTE_USER'"}'
exit 0

/var/www/cgi-bin/fail.cgi

#!/bin/bash
echo "Content-Type: application/json"
echo ""
echo '{"error": "Login failure"}'
exit 0

4.4.7.1. ファイルの要件

Apache HTTPD Web サーバーで作成するファイルの要件は以下のとおりです。

  • login.cgi および fail.cgi は実行可能 (chmod +x) である必要があります。
  • login.cgi および fail.cgi には、SELinux が有効にされている場合、適切な SELinux コンテキストがなければなりません: restorecon -RFv /var/www/cgi-bin、またはコンテキストが ls -laZ を使用して httpd_sys_script_exec_t であることを確認します。
  • login.cgi は、ユーザーが Require and Auth ディレクティブを使用して正常にログインできる場合にのみ実行されます。
  • fail.cgi は、ユーザーがログインに失敗する場合に実行されます (HTTP 401 応答が返されます)。

4.4.8. Basic 認証のトラブルシューティング

最もよく起こる問題は、バックエンドサーバーへのネットワーク接続に関連しています。簡単なデバッグの場合は、マスターで curl コマンドを実行します。正常なログインをテストするには、以下のコマンド例の <user><password> を有効な認証情報に置き換えます。無効なログインをテストするには、それらを正しくない認証情報に置き換えます。

curl --cacert /path/to/ca.crt --cert /path/to/client.crt --key /path/to/client.key -u <user>:<password> -v https://www.example.com/remote-idp

正常な応答

sub (サブジェクト) キーを持つ 200 ステータスは、成功を示しています。

{"sub":"userid"}

サブジェクトは認証ユーザーに固有である必要があり、変更することはできません。

正常な応答により、以下のような追加データがオプションで提供されることがあります。

  • name キーを使用した表示名:

    {"sub":"userid", "name": "User Name", ...}
  • email キーを使用したメールアドレス:

    {"sub":"userid", "email":"user@example.com", ...}
  • preferred_username キーを使用した推奨ユーザー名:

    {"sub":"014fbff9a07c", "preferred_username":"bob", ...}

    preferred_username キーは、固有の変更できないサブジェクトがデータベースキーまたは UID であり、判読可能な名前が存在する場合に便利です。これは、認証されたアイデンティティーの Azure Red Hat OpenShift ユーザーをプロビジョニングする場合にヒントとして使われます。

失敗の応答

  • 401 応答は認証の失敗を示しています。
  • 200 以外のステータスまたは空でない「エラー」キーはエラーを示しています: {"error":"Error message"}

4.5. 要求ヘッダーアイデンティティープロバイダーの設定

request-header アイデンティティープロバイダーを、X-Remote-User などの要求ヘッダー値から識別するように設定します。通常、これは要求ヘッダー値を設定する認証プロキシーと併用されます。

4.5.1. Azure Red Hat OpenShift のアイデンティティープロバイダーについて

デフォルトでは、kubeadmin ユーザーのみがクラスターに存在します。アイデンティティープロバイダーを指定するには、アイデンティティープロバイダーを記述し、これをクラスターに追加するカスタムリソース (CR、Custom Resource) を作成する必要があります。

注記

/:、および % を含む Azure Red Hat OpenShift ユーザー名はサポートされません。

4.5.2. 要求ヘッダー認証について

要求ヘッダーアイデンティティープロバイダーは、X-Remote-User などの要求ヘッダー値からユーザーを識別します。通常、これは要求ヘッダー値を設定する認証プロキシーと併用されます。

注記

さらに、コミュニティーでサポートされる SAML 認証などの詳細な設定に要求ヘッダーアイデンティティープロバイダーを使用できます。このソリューションは Red Hat ではサポートされていないことに注意してください。

ユーザーがこのアイデンティティープロバイダーを使用して認証を行うには、認証プロキシー経由で https://<namespace_route>/oauth/authorize (およびサブパス) にアクセスする必要があります。これを実行するには、OAuth トークンに対する非認証の要求を https://<namespace_route>/oauth/authorize にプロキシー処理するプロキシーエンドポイントにリダイレクトするよう OAuth サーバーを設定します。

ブラウザーベースのログインフローが想定されるクライアントからの非認証要求をリダイレクトするには、以下を実行します。

  • provider.loginURL パラメーターをインタラクティブなクライアントを認証する認証プロキシー URL に設定してから、要求を https://<namespace_route>/oauth/authorize にプロキシーします。

WWW-Authenticate チャレンジが想定されるクライアントからの非認証要求をリダイレクトするには、以下を実行します。

  • provider.challengeURL パラメーターを WWW-Authenticate チャレンジが予想されるクライアントを認証する認証プロキシー URL に設定し、要求を https://<namespace_route>/oauth/authorize にプロキシーします。

provider.challengeURL および provider.loginURL パラメーターには、URL のクエリー部分に以下のトークンを含めることができます。

  • ${url} は現在の URL と置き換えられ、エスケープされてクエリーパラメーターで保護されます。

    例: https://www.example.com/sso-login?then=${url}

  • ${query} は最新のクエリー文字列と置き換えられ、エスケープされません。

    例: https://www.example.com/auth-proxy/oauth/authorize?${query}

重要

Azure Red Hat OpenShift 4.1 の時点で、プロキシーは相互 TLS をサポートする必要があります。

4.5.2.1. Microsoft Windows での SSPI 接続サポート

oc は、Microsoft Windows での SSO フローを許可するために Security Support Provider Interface (SSPI) をサポートします。要求ヘッダーのアイデンティティープロバイダーを GSSAPI 対応プロキシーと共に使用して Active Directory サーバーを Azure Red Hat OpenShift に接続する場合、ユーザーは、ドメイン参加済みの Microsoft Windows コンピューターから oc コマンドラインインターフェースを使用して Azure Red Hat OpenShift に対して自動的に認証されます。

4.5.3. ConfigMap の作成

アイデンティティープロバイダーは、openshift-config namespace で Azure Red Hat OpenShift ConfigMap を使用し、認証局バンドルをこれに組み込みます。これらは、主にアイデンティティープロバイダーで必要な証明書バンドルを組み込むために使用されます。

  • 以下のコマンドを使用して、認証局が含まれる Azure Red Hat OpenShift ConfigMap を定義します。認証局は ConfigMap の ca.crt キーに保存する必要があります。

    $ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config

4.5.4. 要求ヘッダー CR のサンプル

以下のカスタムリソース (CR) は、要求ヘッダーアイデンティティープロバイダーのパラメーターおよび許可される値を示します。

要求ヘッダー CR

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: requestheaderidp 1
    mappingMethod: claim 2
    type: RequestHeader
    requestHeader:
      challengeURL: "https://www.example.com/challenging-proxy/oauth/authorize?${query}" 3
      loginURL: "https://www.example.com/login-proxy/oauth/authorize?${query}" 4
      ca: 5
        name: ca-config-map
      clientCommonNames: 6
      - my-auth-proxy
      headers: 7
      - X-Remote-User
      - SSO-User
      emailHeaders: 8
      - X-Remote-User-Email
      nameHeaders: 9
      - X-Remote-User-Display-Name
      preferredUsernameHeaders: 10
      - X-Remote-User-Login

1
このプロバイダー名は要求ヘッダーのユーザー名にプレフィックスとして付加され、アイデンティティー名が作成されます。
2
このプロバイダーのアイデンティティーとユーザーオブジェクト間にマッピングが確立される方法を制御します。
3
オプション: 非認証の /oauth/authorize 要求のリダイレクト先となる URL です。これは、ブラウザーベースのクライアントを認証し、その要求を https://<namespace_route>/oauth/authorize にプロキシーします。https://<namespace_route>/oauth/authorize にプロキシーする URL は /authorize で終了し (末尾のスラッシュなし)、OAuth 承認フローが適切に機能するようにサブパスもプロキシーします。${url} は現在の URL に置き換えられ、エスケープされてクエリーパラメーターで保護されます。${query} は現在のクエリー文字列に置き換えられます。この属性が定義されない場合は、loginURL が使用される必要があります。
4
オプション: 非認証の /oauth/authorize 要求のリダイレクト先となる URL です。WWW-Authenticate チャレンジが想定されるクライアントを認証し、それらを https://<namespace_route>/oauth/authorize にプロキシーします。 ${url} は現在の URL に置き換えられ、エスケープされてクエリーパラメーターで保護されます。 ${query} は現在のクエリー文字列に置き換えられます。 この属性が定義されない場合は、 challengeURL が使用される必要があります。
5
PEM エンコードされた証明書バンドルを含む Azure Red Hat OpenShift ConfigMap への参照。リモートサーバーによって表示される TLS 証明書を検証するためにトラストアンカーとして使用されます。
重要

Azure Red Hat OpenShift 4.1 の時点で、ca フィールドはこのアイデンティティープロバイダーに必要です。これは、プロキシーが相互 TLS をサポートしている必要があることを意味します。

6
オプション: 共通名 (cn) の一覧。これが設定されている場合は、要求ヘッダーのユーザー名をチェックする前に指定される一覧の Common Name (cn) を持つ有効なクライアント証明書が提示される必要があります。空の場合、すべての Common Name が許可されます。これは caと組み合わせる場合にのみ使用できます。
7
ユーザーアイデンティティーを順番にチェックする際に使用するヘッダー名。値を含む最初のヘッダーはアイデンティティーとして使用されます。これは必須であり、大文字小文字を区別します。
8
メールアドレスを順番にチェックする際に使用するヘッダー名。値を含む最初のヘッダーはメールアドレスとして使用されます。これは任意であり、大文字小文字を区別します。
9
表示名を順番にチェックする際に使用するヘッダー名。値を含む最初のヘッダーは表示名として使用されます。これは任意であり、大文字小文字を区別します。
10
推奨ユーザー名を順番にチェックする際に使用するヘッダー名 ( headers に指定されるヘッダーで決定される変更不可のアイデンティティーと異なる場合)。値を含む最初のヘッダーは、プロビジョニング時に推奨ユーザー名として使用されます。これは任意であり、大文字小文字を区別します。

4.5.5. アイデンティティープロバイダーのクラスターへの追加

クラスターのインストール後に、アイデンティティープロバイダーをそのクラスターに追加し、ユーザーの認証を実行できるようにします。

前提条件

  • Azure Red Hat OpenShift クラスターを作成します。
  • アイデンティティープロバイダーのカスタムリソース (CR) を作成します。
  • 管理者としてログインしている必要があります。

手順

  1. 定義された CR を適用します。

    $ oc apply -f </path/to/CR>
    注記

    CR が存在しない場合、oc apply は新規 CR を作成し、さらに以下の警告をトリガーする可能性があります。Warning: oc apply should be used on resources created by either oc create --save-config or oc applyこの場合は、この警告を無視しても問題ありません。

  2. アイデンティティープロバイダーのユーザーとしてクラスターにログインし、プロンプトが出されたらパスワードを入力します。

    $ oc login -u <username>
  3. ユーザーが正常にログインされていることを確認し、ユーザー名を表示します。

    $ oc whoami

4.5.6. 要求ヘッダーを使用した Apache 認証設定の例

この例では、要求ヘッダーアイデンティティープロバイダーを使用して Azure Red Hat OpenShift の Apache 認証プロキシーを設定します。

カスタムプロキシー設定

mod_auth_gssapi モジュールの使用は、要求ヘッダーアイデンティティープロバイダーを使用して Apache 認証プロキシーを設定する一般的な方法ですが、必須の方法ではありません。以下の要件を満たすと、他のプロキシーを簡単に使用できます。

  • クライアント要求の X-Remote-User ヘッダーをブロックして、スプーフィングを防ぎます。
  • RequestHeaderIdentityProvider 設定でクライアント証明書の認証を適用します。
  • チャレンジフローを使用してすべての認証要求についての X-Csrf-Token ヘッダーを設定する必要があります。
  • /oauth/authorize エンドポイントとそのサブパスのみがプロキシーされる必要があります。バックエンドサーバーがクライアントを正しい場所に送信できるようリダイレクトは書き換える必要があります。
  • https://<namespace_route>/oauth/authorize にプロキシーする URL は /authorize で終了 (末尾のスラッシュなし) する必要があります。たとえば、https://proxy.example.com/login-proxy/authorize?…​https://<namespace_route>/oauth/authorize?…​ にプロキシーする必要があります。
  • https://<namespace_route>/oauth/authorize にプロキシーされる URL のサブパスは、https://<namespace_route>/oauth/authorize にプロキシーする必要があります。たとえば、https://proxy.example.com/login-proxy/authorize/approve?…​https://<namespace_route>/oauth/authorize/approve?…​ にプロキシーする必要があります。
注記

https://<namespace_route> アドレスは OAuth サーバーへのルートであり、oc get route -n openshift-authentication を実行して取得できます。

要求ヘッダーを使用した Apache 認証の設定

この例では、mod_auth_gssapi モジュールを使用し、要求ヘッダーアイデンティティープロバイダーを使用して Apache 認証プロキシーを設定します。

前提条件

  • mod_auth_gssapi モジュールを Optional チャンネルから取得します。ローカルマシンに以下のパッケージをインストールする必要があります。

    • httpd
    • mod_ssl
    • mod_session
    • apr-util-openssl
    • mod_auth_gssapi
  • 信頼されたヘッダーを送信する要求を検証するために CA を生成します。CA を含む Azure Red Hat OpenShift ConfigMap を定義します。これは、以下を実行して行います。

    $ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config

    CA は、ConfigMap の ca.crt キーに保存する必要があります。

  • このプロキシー用のクライアント証明書を生成します。この証明書は、x509 証明書ツールを使用して生成できます。信頼されたヘッダーを送信する要求を検証するために、生成した CA でクライアント証明書に署名する必要があります。
  • アイデンティティープロバイダーのカスタムリソース (CR) を作成します。

手順

このプロキシーはクライアント証明書を使用して OAuth サーバーに接続します。これは、X-Remote-User ヘッダーを信頼するように設定されます。

  1. Apache 設定の証明書を作成します。SSLProxyMachineCertificateFile パラメーターの値として指定する証明書は、プロキシーをサーバーに対して認証するために使用されるプロキシーのクライアント証明書です。これは、拡張されたキーのタイプとして TLS Web Client Authentication を使用する必要があります。
  2. Apache 設定を作成します。以下のテンプレートを使用して必要な設定および値を指定します。

    重要

    テンプレートを十分に確認し、その内容を環境に合うようにカスタマイズします。

    LoadModule request_module modules/mod_request.so
    LoadModule auth_gssapi_module modules/mod_auth_gssapi.so
    # Some Apache configurations might require these modules.
    # LoadModule auth_form_module modules/mod_auth_form.so
    # LoadModule session_module modules/mod_session.so
    
    # Nothing needs to be served over HTTP.  This virtual host simply redirects to
    # HTTPS.
    <VirtualHost *:80>
      DocumentRoot /var/www/html
      RewriteEngine              On
      RewriteRule     ^(.*)$     https://%{HTTP_HOST}$1 [R,L]
    </VirtualHost>
    
    <VirtualHost *:443>
      # This needs to match the certificates you generated.  See the CN and X509v3
      # Subject Alternative Name in the output of:
      # openssl x509 -text -in /etc/pki/tls/certs/localhost.crt
      ServerName www.example.com
    
      DocumentRoot /var/www/html
      SSLEngine on
      SSLCertificateFile /etc/pki/tls/certs/localhost.crt
      SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
      SSLCACertificateFile /etc/pki/CA/certs/ca.crt
    
      SSLProxyEngine on
      SSLProxyCACertificateFile /etc/pki/CA/certs/ca.crt
      # It is critical to enforce client certificates. Otherwise, requests can
      # spoof the X-Remote-User header by accessing the /oauth/authorize endpoint
      # directly.
      SSLProxyMachineCertificateFile /etc/pki/tls/certs/authproxy.pem
    
      # To use the challenging-proxy, an X-Csrf-Token must be present.
      RewriteCond %{REQUEST_URI} ^/challenging-proxy
      RewriteCond %{HTTP:X-Csrf-Token} ^$ [NC]
      RewriteRule ^.* - [F,L]
    
      <Location /challenging-proxy/oauth/authorize>
          # Insert your backend server name/ip here.
          ProxyPass https://<namespace_route>/oauth/authorize
          AuthName "SSO Login"
          # For Kerberos
          AuthType GSSAPI
          Require valid-user
          RequestHeader set X-Remote-User %{REMOTE_USER}s
    
          GssapiCredStore keytab:/etc/httpd/protected/auth-proxy.keytab
          # Enable the following if you want to allow users to fallback
          # to password based authentication when they do not have a client
          # configured to perform kerberos authentication.
          GssapiBasicAuth On
    
          # For ldap:
          # AuthBasicProvider ldap
          # AuthLDAPURL "ldap://ldap.example.com:389/ou=People,dc=my-domain,dc=com?uid?sub?(objectClass=*)"
        </Location>
    
        <Location /login-proxy/oauth/authorize>
        # Insert your backend server name/ip here.
        ProxyPass https://<namespace_route>/oauth/authorize
    
          AuthName "SSO Login"
          AuthType GSSAPI
          Require valid-user
          RequestHeader set X-Remote-User %{REMOTE_USER}s env=REMOTE_USER
    
          GssapiCredStore keytab:/etc/httpd/protected/auth-proxy.keytab
          # Enable the following if you want to allow users to fallback
          # to password based authentication when they do not have a client
          # configured to perform kerberos authentication.
          GssapiBasicAuth On
    
          ErrorDocument 401 /login.html
        </Location>
    
    </VirtualHost>
    
    RequestHeader unset X-Remote-User
    注記

    https://<namespace_route> アドレスは OAuth サーバーへのルートであり、oc get route -n openshift-authentication を実行して取得できます。

  3. カスタムリソース (CR) の identityProviders スタンザを更新します。

    identityProviders:
      - name: requestheaderidp
        type: RequestHeader
        requestHeader:
          challengeURL: "https://<namespace_route>/challenging-proxy/oauth/authorize?${query}"
          loginURL: "https://<namespace_route>/login-proxy/oauth/authorize?${query}"
          ca:
            name: ca-config-map
            clientCommonNames:
            - my-auth-proxy
            headers:
            - X-Remote-User
  4. 設定を確認します。

    1. 適切なクライアント証明書およびヘッダーを指定して、トークンを要求し、プロキシーをバイパスできることを確認します。

      # curl -L -k -H "X-Remote-User: joe" \
         --cert /etc/pki/tls/certs/authproxy.pem \
         https://<namespace_route>/oauth/token/request
    2. クライアント証明書を提供しない要求が、証明書なしでトークンを要求して失敗することを確認します。

      # curl -L -k -H "X-Remote-User: joe" \
         https://<namespace_route>/oauth/token/request
    3. challengeURL リダイレクトがアクティブであることを確認します。

      # curl -k -v -H 'X-Csrf-Token: 1' \
         https://<namespace_route>/oauth/authorize?client_id=openshift-challenging-client&response_type=token

      以下の手順で使用する challengeURL リダイレクトをコピーします。

    4. このコマンドを実行して、WWW-Authenticate 基本チャレンジ、ネゴシエートチャレンジ、またはそれらの両方のチャレンジを含む 401 応答を表示します。

      # curl -k -v -H 'X-Csrf-Token: 1' \
         <challengeURL_redirect + query>
    5. Kerberos チケットを使用または使用せずに、OpenShift CLI (oc) へのログインをテストします。

      1. kinit を使用して Kerberos チケットを生成した場合は、これを破棄します。

        # kdestroy -c cache_name 1
        1
        Kerberos キャッシュの名前を指定します。
      2. Kerberos 認証情報を使用して oc ツールにログインします。

        # oc login

        プロンプトで、Kerberos ユーザー名およびパスワードを入力します。

      3. oc ツールからログアウトします。

        # oc logout
      4. Kerberos 認証情報を使用してチケットを取得します。

        # kinit

        プロンプトで、Kerberos ユーザー名およびパスワードを入力します。

      5. oc ツールにログインできることを確認します。

        # oc login

        設定が正しい場合は、別の認証情報を入力せずにログインできます。

4.6. GitHub または GitHub Enterprise アイデンティティープロバイダーの設定

github アイデンティティープロバイダーを、GitHub または GitHub Enterprise の OAuth 認証サーバーに対してユーザー名とパスワードを検証するように設定します。OAuth は Azure Red Hat OpenShift と GitHub または GitHub Enterprise 間のトークン交換フローを容易にします。

GitHub 統合を使用して GitHub または GitHub Enterprise のいずれかに接続できます。GitHub Enterprise 統合の場合、インスタンスの hostname を指定する必要があり、サーバーへの要求で使用する ca 証明書バンドルをオプションで指定することができます。

注記

とくに記述がない限り、以下の手順が GitHub および GitHub Enterprise の両方に適用されます。

GitHub 認証を設定することによって、ユーザーは GitHub 認証情報を使用して Azure Red Hat OpenShift にログインできます。GitHub ユーザー ID を持つすべてのユーザーが Azure Red Hat OpenShift クラスターにログインできないようにするために、アクセスを特定の GitHub 組織のユーザーに制限することができます。

4.6.1. GitHub アプリケーションの登録

GitHub または GitHub Enterprise をアイデンティティープロバイダーとして使用するには、使用するアプリケーションを登録する必要があります。

手順

  1. アプリケーションを GitHub で登録します。

    • GitHub の場合、「Settings」 → 「Developer settings」 → 「OAuth Apps」 → 「Register a new OAuth application」をクリックします。
    • GitHub Enterprise の場合は、GitHub Enterprise ホームページに移動してから 「Settings」 → 「Developer settings」 → 「Register a new application」 をクリックします。
  2. アプリケーション名を入力します (例: My OpenShift Install)。
  3. ホームページ URL (例: https://oauth-openshift.apps.<cluster-name>.<cluster-domain>) を入力します。
  4. オプション: アプリケーションの説明を入力します。
  5. 認可コールバック URL を入力します。 ここで、URL の終わりにはアイデンティティープロバイダーの name が含まれます。

    https://oauth-openshift.apps.<cluster-name>.<cluster-domain>/oauth2callback/<idp-provider-name>

    以下は例になります。

    https://oauth-openshift.apps.example-openshift-cluster.com/oauth2callback/github/
  6. Register application をクリックします。GitHub はクライアント ID とクライアントシークレットを提供します。これらの値は、アイデンティティープロバイダーの設定を完了するために必要です。

4.7. GitLab アイデンティティープロバイダーの設定

gitlab アイデンティティープロバイダーを、GitLab.com またはその他の GitLab インスタンスをアイデンティティープロバイダーとして使用するように設定します。GitLab バージョン 7.7.0 から 11.0 を使用する場合、OAuth 統合を使用して接続します。GitLab バージョン 11.1 以降の場合、OAuth ではなく OpenID Connect (OIDC) を使用して接続します。

4.7.1. シークレットの作成

アイデンティティープロバイダーは openshift-config namespace で Azure Red Hat OpenShift シークレットを使用して、クライアントシークレット、クライアント証明書およびキーをこれに組み込みます。

  • 以下のコマンドを使用して、Azure Red Hat OpenShift シークレットを定義できます。

    $ oc create secret generic <secret_name> --from-literal=clientSecret=<secret> -n openshift-config
  • 以下のコマンドを実行して、証明書ファイルなどのファイルの内容を含む Azure Red Hat OpenShift シークレットを定義できます。

    $ oc create secret generic <secret_name> --from-file=/path/to/file -n openshift-config

4.7.2. ConfigMap の作成

アイデンティティープロバイダーは、openshift-config namespace で Azure Red Hat OpenShift ConfigMap を使用し、認証局バンドルをこれに組み込みます。これらは、主にアイデンティティープロバイダーで必要な証明書バンドルを組み込むために使用されます。

  • 以下のコマンドを使用して、認証局が含まれる Azure Red Hat OpenShift ConfigMap を定義します。認証局は ConfigMap の ca.crt キーに保存する必要があります。

    $ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config

4.7.3. GitLab CR のサンプル

以下のカスタムリソース (CR) は、GitLab アイデンティティープロバイダーのパラメーターおよび許可される値を示します。

GitLab CR

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: gitlabidp 1
    mappingMethod: claim 2
    type: GitLab
    gitlab:
      clientID: {...} 3
      clientSecret: 4
        name: gitlab-secret
      url: https://gitlab.com 5
      ca: 6
        name: ca-config-map

1
このプロバイダー名は GitLab 数字ユーザー ID にプレフィックスとして付加され、アイデンティティー名が作成されます。これはコールバック URL を作成するためにも使用されます。
2
このプロバイダーのアイデンティティーとユーザーオブジェクト間にマッピングが確立される方法を制御します。
3
登録済みの GitLab OAuth アプリケーションのクライアント ID です。アプリケーションは、https://oauth-openshift.apps.<cluster-name>.<cluster-domain>/oauth2callback/<idp-provider-name> のコールバック URL を使用して設定する必要があります。
4
GitLab で発行されるクライアントシークレットが含まれる Azure Red Hat OpenShift シークレットへの参照。
5
GitLab プロバイダーのホスト URL です。これは https://gitlab.com/ か、または他の GitLab の自己ホストインスタンスのいずれかになります。
6
オプション: 設定済みの URL のサーバー証明書を検証するために使用する PEM エンコードされた認証局バンドルを含む Azure Red Hat OpenShift ConfigMap への参照。

4.7.4. アイデンティティープロバイダーのクラスターへの追加

クラスターのインストール後に、アイデンティティープロバイダーをそのクラスターに追加し、ユーザーの認証を実行できるようにします。

前提条件

  • Azure Red Hat OpenShift クラスターを作成します。
  • アイデンティティープロバイダーのカスタムリソース (CR) を作成します。
  • 管理者としてログインしている必要があります。

手順

  1. 定義された CR を適用します。

    $ oc apply -f </path/to/CR>
    注記

    CR が存在しない場合、oc apply は新規 CR を作成し、さらに以下の警告をトリガーする可能性があります。Warning: oc apply should be used on resources created by either oc create --save-config or oc applyこの場合は、この警告を無視しても問題ありません。

  2. アイデンティティープロバイダーのユーザーとしてクラスターにログインし、プロンプトが出されたらパスワードを入力します。

    $ oc login -u <username>
  3. ユーザーが正常にログインされていることを確認し、ユーザー名を表示します。

    $ oc whoami

4.8. Google アイデンティティープロバイダーの設定

google アイデンティティープロバイダーを、Google の OpenID Connect 統合を使用して設定します。

注記

Google をアイデンティティープロバイダーとして使用するには、<master>/oauth/token/request を使用してトークンを取得し、コマンドラインツールで使用する必要があります。

警告

Google をアイデンティティープロバイダーとして使用することで、Google ユーザーはサーバーに対して認証されます。hostedDomain 設定属性を使用して、特定のホストドメインのメンバーに認証を限定することができます。

4.9. OpenID Connect アイデンティティープロバイダーの設定

oidc アイデンティティープロバイダーを、Authorization Code Flowを使用して OpenID Connect アイデンティティープロバイダーと統合するように設定します。

重要

Azure Red Hat OpenShift の認証 Operator では、設定済みの OpenID Connect アイデンティティープロバイダーが OpenID Connect Discovery 仕様を実装する必要があります。

注記

ID Token および UserInfo の復号化はサポートされていません。

デフォルトで、openid の範囲が要求されます。必要な場合は、extraScopes フィールドで追加の範囲を指定できます。

要求は、OpenID アイデンティティープロバイダーから返される JWT id_token から読み取られ、指定される場合は UserInfo URL によって返される JSON から読み取られます。

1 つ以上の要求をユーザーのアイデンティティーを使用するように設定される必要があります。標準のアイデンティティー要求は sub になります。

また、どの要求をユーザーの推奨ユーザー名、表示名およびメールアドレスとして使用するか指定することができます。複数の要求が指定されている場合、値が入力されている最初の要求が使用されます。標準のアイデンティティー要求は以下の通りです。

sub

「subject identifier」の省略形です。 発行側のユーザーのリモートアイデンティティーです。

preferred_username

ユーザーのプロビジョニング時に優先されるユーザー名です。janedoe などのユーザーを参照する際に使用する省略形の名前です。通常は、ユーザー名またはメールなどの、認証システムのユーザーのログインまたはユーザー名に対応する値です。

email

メールアドレス。

name

表示名。

詳細は、OpenID claim のドキュメント を参照してください。

注記

OpenID Connect アイデンティティープロバイダーを使用するには、<master>/oauth/token/request を使用してトークンを取得し、コマンドラインツールで使用する必要があります。

第5章 証明書の設定

5.1. デフォルトの Ingress 証明書の置き換え

5.1.1. デフォルトの Ingress 証明書について

デフォルトで、Azure Red Hat OpenShift は Ingress Operator を使用して内部 CA を作成し、 .apps サブドメインの下にあるアプリケーションに有効なワイルドカード証明書を発行します。Web コンソールと CLI のどちらもこの証明書を使用します。

内部インフラストラクチャー CA 証明書は自己署名型です。一部のセキュリティーまたは PKI チームにとってこのプロセスは適切とみなされない可能性がありますが、ここで想定されるリスクは最小限度のものです。これらの証明書を暗黙的に信頼するクライアントがクラスター内の他のコンポーネントになります。デフォルトのワイルドカード証明書を、コンテナーユーザー空間で提供される CA バンドルにすでに含まれているパブリック CA に置き換えることで、外部クライアントは .apps サブドメインで実行されるアプリケーションに安全に接続できます。

5.1.2. デフォルトの Ingress 証明書の置き換え

.apps サブドメインにあるすべてのアプリケーションのデフォルトの Ingress 証明書を置き換えることができます。証明書を置き換えた後に、Web コンソールや CLI を含むすべてのアプリケーションには、指定された証明書で提供される暗号化が設定されます。

前提条件

  • ワイルドカード証明書およびそのプライベートキー (どちらも PEM 形式) を使用できる必要があります。
  • 証明書には、*.apps.<clustername>.<domain> subjectAltName 拡張がなければなりません。

手順

  1. 新しい証明書に署名するために使用される認証局が含まれる ConfigMap を作成します。

    $ oc create configmap custom-ca \
         --from-file=ca-bundle.crt=</path/to/example-ca.crt> \1
         -n openshift-config
    1
    </path/to/example-ca.crt> は、ローカルファイルシステム上の認証局ファイルへのパスです。
  2. 新たに作成された ConfigMap でクラスター全体のプロキシー設定を更新します。

    $ oc patch proxy/cluster \
         --type=merge \
         --patch='{"spec":{"trustedCA":{"name":"custom-ca"}}}'
  3. ワイルドカード証明書およびキーが含まれるシークレットを作成します。

    $ oc create secret tls <certificate> \1
         --cert=</path/to/cert.crt> \2
         --key=</path/to/cert.key> \3
         -n openshift-ingress
    1
    <certificate> は、証明書およびプライベートキーが含まれるシークレットの名前です。
    2
    </path/to/cert.crt> は、ローカルファイルシステム上の証明書へのパスです。
    3
    </path/to/cert.key> は、この証明書に関連付けられるプライベートキーへのパスです。
  4. Ingress コントローラー設定を、新規に作成されたシークレットで更新します。

    $ oc patch ingresscontroller.operator default \
         --type=merge -p \
         '{"spec":{"defaultCertificate": {"name": "<certificate>"}}}' \1
         -n openshift-ingress-operator
    1
    <certificate> を、直前の手順のシークレットで使用された名前に置き換えます。

5.2. API サーバー証明書の追加

デフォルトの API サーバー証明書は、内部 Azure Red Hat OpenShift クラスター CA によって発行されます。クラスター外のクライアントは、デフォルトで API サーバーの証明書を検証できません。この証明書は、クライアントが信頼する CA によって発行される証明書に置き換えることができます。

5.2.1. API サーバーの名前付き証明書の追加

デフォルトの API サーバー証明書は、内部 Azure Red Hat OpenShift クラスター CA によって発行されます。リバースプロキシーやロードバランサーが使用される場合などに、クライアントの要求 URLに基づいて送信できるように証明書を API サーバーに追加できます。

前提条件

  • クライアントの URL についての PEM 形式の証明書およびキーが必要です。
  • 証明書は、API サーバーに到達できるように、クライアントによって使用される URL について発行される必要があります。
  • 証明書には、URL の subjectAltName 拡張がなければなりません。
  • サーバー証明書の認証に証明書チェーンが必要な場合は、証明書チェーンをサーバー証明書に追加する必要があります。証明書ファイルは Base64 PEM でエンコードされており、通常は .crt または .pem 拡張があります。以下は例になります。

    $ cat server_cert.pem int2ca_cert.pem int1ca_cert.pem rootca_cert.pem>combined_cert.pem

    証明書を組み合わせる際には、証明書の順序が重要になります。以下の証明書はその前にある証明書を直接認証する必要があります。たとえば、以下のようになります。

    1. Azure Red Hat OpenShift マスターホストサーバー証明書。
    2. サーバー証明書を認定する中間 CA 証明書。
    3. 中間 CA 証明書を認定するルート CA 証明書。
警告

内部ロードバランサーに名前付きの証明書を指定しないようにしてください (ホスト名 api-int.<cluster_name>.<base_domain>)。これを指定すると、クラスターの状態は動作の低下した状態になります。

手順

  1. openshift-config namespace に証明書およびキーが含まれるシークレットを作成します。

    $ oc create secret tls <certificate> \1
         --cert=</path/to/cert.crt> \2
         --key=</path/to/cert.key> \3
         -n openshift-config
    1
    <certificate> は、証明書が含まれるシークレットの名前です。
    2
    </path/to/cert.crt> は、ローカルファイルシステム上の証明書へのパスです。
    3
    </path/to/cert.key> は、この証明書に関連付けられるプライベートキーへのパスです。
  2. API サーバーを作成されたシークレットを参照するように更新します。

    $ oc patch apiserver cluster \
         --type=merge -p \
         '{"spec":{"servingCerts": {"namedCertificates":
         [{"names": ["<hostname>"], 1
         "servingCertificate": {"name": "<certificate>"}}]}}}' 2
    1
    <hostname> を、API サーバーが証明書を提供するホスト名に置き換えます。
    2
    <certificate> を、直前の手順のシークレットで使用された名前に置き換えます。
  3. apiserver/cluster オブジェクトを検査し、シークレットが参照されていることを確認します。

    $ oc get apiserver cluster -o yaml
    ...
    spec:
      servingCerts:
        namedCertificates:
        - names:
          - <hostname>
          servingCertificate:
            name: <certificate>
    ...

5.3. サービス提供証明書のシークレットによるサービストラフィックのセキュリティー保護

5.3.1. サービス提供証明書について

サービス提供証明書は、暗号化を必要とする複雑なミドルウェアアプリケーションをサポートすることが意図されています。これらの証明書は、TLS Web サーバー証明書として発行されます。

service-ca コントローラーは、サービス証明書を生成するために x509.SHA256WithRSA 署名アルゴリズムを使用します。

生成される証明書およびキーは PEM 形式のもので、作成されたシークレット内の tls.crt および tls.key にそれぞれ保存されます。証明書およびキーは、有効期間に近づくと自動的に置き換えられます。

サービス証明書を発行するサービス CA 証明書は 26 ヵ月間有効であり、有効期間が 6 ヵ月未満になると自動的にローテーションされます。ローテーション後も、直前のサービス CA 設定は有効期限が切れるまで信頼されます。これにより、影響を受けるすべてのサービスについて、期限が切れる前にそれらのキーの情報を更新できるように猶予期間が許可されます。この猶予期間中にクラスターをアップグレード(サービスを再起動してそれらのキー情報を更新する)を実行しない場合、直前のサービス CA の期限が切れた後の失敗を防ぐためにサービスを手動で再起動する必要がある場合があります。

注記

以下のコマンドを使用して、クラスター内のすべての Pod を手動で再起動できます。このコマンドは、すべての namespace で実行されているすべての Pod を削除するため、このコマンドを実行するとサービスが中断します。これらの Pod は削除後に自動的に再起動します。

$ for I in $(oc get ns -o jsonpath='{range .items[*]} {.metadata.name}{"\n"} {end}'); \
      do oc delete pods --all -n $I; \
      sleep 1; \
      done

5.3.2. サービス証明書の追加

サービスとの通信のセキュリティーを保護するには、サービスと同じ namespace のシークレットに署名済みの提供証明書とキーのペアを生成します。

重要

生成される証明書は、内部サービス DNS 名 <service.name>.<service.namespace>.svc にのみ有効であり、内部通信用にのみ有効です。

前提条件

  • サービスが定義されていること。

手順

  1. サービスに service.beta.openshift.io/serving-cert-secret-name のアノテーションを付けます。

    $ oc annotate service <service-name> \1
         service.beta.openshift.io/serving-cert-secret-name=<secret-name> 2
    1
    <service-name> を、セキュリティー保護するサービスの名前に置き換えます。
    2
    <secret-name> は、証明書とキーのペアを含む生成されたシークレットの名前です。便宜上、これを <service-name> と同じにすることが推奨されます。

    たとえば、以下のコマンドを使用してサービス foo にアノテーションを付けます。

    $ oc annotate service foo service.beta.openshift.io/serving-cert-secret-name=foo
  2. アノテーションが存在することを確認するためにサービスを検査します。

    $ oc describe service <service-name>
    ...
    Annotations:              service.beta.openshift.io/serving-cert-secret-name: <service-name>
                              service.beta.openshift.io/serving-cert-signed-by: openshift-service-serving-signer@1556850837
    ...
  3. クラスターがサービスのシークレットを生成した後に、 PodSpec がこれをマウントでき、Pod はシークレットが利用可能になった後にこれを実行できます。

5.3.3. サービス証明書の ConfigMap への追加

Pod は、service.beta.openshift.io/inject-cabundle=true のアノテーションの付いた ConfigMap をマウントしてサービス CA 証明書にアクセスできます。アノテーションが付けられると、クラスターはサービス CA 証明書を ConfigMap のservice-ca.crt キーに自動的に挿入します。この CA 証明書にアクセスできると、TLS クライアントはサービス提供証明書を使用してサービスへの接続を検証できます。

重要

このアノテーションが ConfigMap に追加されると、その中に含まれるすべての既存データが削除されます。service-ca.crt を組み込む ConfigMap としては、Pod の設定の保存先と同じ ConfigMap ではなく、別の ConfigMap を使用することが推奨されます。

手順

  1. ConfigMap に service.beta.openshift.io/inject-cabundle=true のアノテーションを付けます。

    $ oc annotate configmap <configmap-name> \1
         service.beta.openshift.io/inject-cabundle=true
    1
    <configmap-name> を、アノテーションを付ける ConfigMap の名前に置き換えます。
    注記

    volumeMount の service-ca.crt キーを明示的に参照することにより、ConfigMap が CA バンドルと共に挿入されるまで、Pod を起動できなくなります。

    たとえば、ConfigMap foo にアノテーションを付けるには、以下のコマンドを使用します。

    $ oc annotate configmap foo service.beta.openshift.io/inject-cabundle=true
  2. 証明書が生成されていることを確認するために ConfigMap を表示します。これは、YAML 出力の service-ca.crt として表示されます。

    $ oc get configmap <configmap-name> -o yaml
    apiVersion: v1
    data:
      service-ca.crt: |
        -----BEGIN CERTIFICATE-----
    ...

5.3.4. 生成されたサービス証明書の手動によるローテーション

関連付けられたシークレットを削除することにより、サービス証明書をローテーションできます。シークレットを削除すると、新規のシークレットが自動的に作成され、新規証明書が作成されます。

前提条件

  • 証明書とキーのペアを含むシークレットがサービス用に生成されていること。

手順

  1. 証明書を含むシークレットを確認するためにサービスを検査します。これは、以下に示すように serving-cert-secret-name アノテーションにあります。

    $ oc describe service <service-name>
    ...
    service.beta.openshift.io/serving-cert-secret-name: <secret>
    ...
  2. サービスの生成されたシークレットを削除します。このプロセスで、シークレットが自動的に再作成されます。

    $ oc delete secret <secret> 1
    1
    <secret> を、直前の手順のシークレットの名前に置き換えます。
  3. 新規シークレットを取得し、AGE を調べて、証明書が再作成されていることを確認します。

    $ oc get secret <service-name>
    
    NAME              TYPE                DATA   AGE
    <service.name>    kubernetes.io/tls   2      1s

5.3.5. サービス CA 証明書の手動によるローテーション

サービス CA は 26 ヵ月間有効で、有効期間が 6 ヵ月未満になると自動的に更新されます。

必要に応じて、以下の手順でサービス CA を手動で更新することができます。

警告

手動でローテーションされたサービス CA は、直前のサービス CA で信頼を維持しません。クラスターの Pod が再起動するまでサービスが一時的に中断する可能性があります。これにより、Pod が新規サービス CA で発行されるサービス提供証明書を使用できるようになります。

前提条件

  • クラスター管理者としてログインしている必要があります。

手順

  1. 以下のコマンドを使用して、現在のサービス CA 証明書の有効期限を表示します。

    $ oc get secrets/signing-key -n openshift-service-ca \
         -o template='{{index .data "tls.crt"}}' \
         | base64 -d \
         | openssl x509 -noout -enddate
  2. サービス CA を手動でローテーションします。このプロセスは、新規サービス証明書に署名するために使用される新規サービス CA を生成します。

    $ oc delete secret/signing-key -n openshift-service-ca
  3. 新規証明書をすべてのサービスに適用するには、クラスター内のすべての Pod を再起動します。このコマンドにより、すべてのサービスが更新された証明書を使用するようになります。

    $ for I in $(oc get ns -o jsonpath='{range .items[*]} {.metadata.name}{"\n"} {end}'); \
          do oc delete pods --all -n $I; \
          sleep 1; \
          done
    警告

    このコマンドは、すべての namespace で実行されているすべての Pod を調べ、これらを削除するため、サービスを中断させます。これらの Pod は削除後に自動的に再起動します。

第6章 RBAC の使用によるパーミッションの定義および適用

6.1. RBAC の概要

Role-based Access Control (RBAC: ロールベースアクセス制御) オブジェクトは、ユーザーがプロジェクト内で所定のアクションを実行することが許可されるかどうかを決定します。

これにより、プラットフォーム管理者はクラスターロールおよびバインディングを使用して、Azure Red Hat OpenShift プラットフォーム自体およびすべてのプロジェクトへの各種のアクセスレベルを持つユーザーを制御できます。

開発者はローカルロールとバインディングを使用して、プロジェクトにアクセスできるユーザーを制御できます。認可は、認証とは異なる別の手順であることに注意してください。 認可の手順は、アクションを実行するユーザーのアイデンティティーの判別により密接に関連しています。

認可は以下を使用して管理されます。

ルール

オブジェクトのセットで許可されている動詞のセット(例: ユーザーまたはサービスアカウントが Pod を create を実行できるかどうか)

ロール

ルールのコレクション。ユーザーおよびグループを複数のロールに関連付けたり、バインドしたりできます。

バインディング

ロールを使ったユーザーおよび/グループ間の関連付けです。

ローカルバインディングとクラスターバインディングについての違いに留意してください。ローカルのロールバインディングを使用して cluster-admin ロールをユーザーにバインドする場合、このユーザーがクラスター管理者の特権を持っているように表示されますが、実際にはそうではありません。 一方、 cluster-admin をプロジェクトのユーザーにバインドすると、そのプロジェクトにのみ有効なスーパー管理者の権限がそのユーザーに付与されます。そのユーザーはクラスターロール adminのパーミッションを有するほか、レート制限を編集する機能などの、そのプロジェクトについてのいくつかの追加パーミッションを持ちます。このバインディングは、クラスター管理者にバインドされるクラスターのロールバインディングを一覧表示しない Web コンソール UI を使うと分かりにくくなります。ただし、これは、cluster-adminをローカルにバインドするために使用するローカルのロールバインディングを一覧表示します。

クラスターロール、クラスターロールのバインディング、ローカルロールのバインディング、ユーザー、グループおよびサービスアカウントの関係は以下に説明されています。

Azure Red Hat OpenShift RBAC

6.1.1. 認可の評価

Azure Red Hat OpenShift は以下を使用して認可を評価します。

アイデンティティー
ユーザーが属するユーザー名とグループの一覧。
アクション

実行する動作。ほとんどの場合、これは以下で構成されます。

  • プロジェクト: アクセスするプロジェクト。プロジェクトは追加のアノテーションを含む Kubernetes namespace であり、これにより、ユーザーのコミュニティーは、他のコミュニティーと分離された状態で独自のコンテンツを編成し、管理できます。
  • 動詞: getlistcreateupdatedeletedeletecollection、または watch などのアクション自体。
  • リソース名: アクセスする API エンドポイント。
バインディング
バインディングの詳細な一覧、ロールを持つユーザーまたはグループ間の関連付け。

Azure Red Hat OpenShift は以下の手順を使って認可を評価します。

  1. アイデンティティーおよびプロジェクトでスコープ設定されたアクションは、ユーザーおよびそれらのグループに適用されるすべてのバインディングを検索します。
  2. バインディングは、適用されるすべてのロールを見つけるために使用されます。
  3. ロールは、適用されるすべてのルールを見つけるために使用されます。
  4. 一致を見つけるために、アクションが各ルールに対してチェックされます。
  5. 一致するルールが見つからない場合、アクションはデフォルトで拒否されます。

それぞれが関連付けられている動詞およびリソースのマトリクスが含まれます。

6.2. プロジェクトおよび namespace

Kubernetes namespace は、クラスターでスコープ設定するメカニズムを提供します。namespace の詳細は、Kubernetes ドキュメントを参照してください。

Namespace は以下の一意のスコープを提供します。

  • 基本的な命名の衝突を避けるための名前付きリソース。
  • 信頼されるユーザーに委任された管理権限。
  • コミュニティーリソースの消費を制限する機能。

システム内の大半のオブジェクトのスコープは namespace で設定されますが、一部はノードやユーザーを含め、除外され、namaspace が設定されません。

プロジェクト は追加のアノテーションを持つ Kubernetes namespace であり、通常ユーザーのリソースへのアクセスが管理される中心的な手段です。プロジェクトはユーザーのコミュニティーが他のコミュニティーとは切り離してコンテンツを編成し、管理することを許可します。ユーザーには、管理者によってプロジェクトへのアクセスが付与される必要があり、許可される場合はプロジェクトを作成でき、それらの独自のプロジェクトへのアクセスが自動的に付与されます。

プロジェクトには、別個の namedisplayName、および description を設定できます。

  • 必須の name はプロジェクトの一意の ID であり、CLI ツールまたは API を使用する場合に最も明確に表示されます。名前の最大長さは 63 文字です。
  • オプションの displayName は、Web コンソールでのプロジェクトの表示方法を示します (デフォルトは name に設定される)。
  • オプションの description には、プロジェクトのさらに詳細な記述を使用でき、これも Web コンソールで表示できます。

各プロジェクトは、以下の独自のセットのスコープを設定します。

Objects

Pod、サービス、レプリケーションコントローラーなど。

Policies

ユーザーがオブジェクトに対してアクションを実行できるか、できないかについてのルール。

Constraints

制限を設定できるそれぞれの種類のオブジェクトのクォータ。

service account (サービスアカウント)

サービスアカウントは、プロジェクトのオブジェクトへの指定されたアクセスで自動的に機能します。

クラスター管理者はプロジェクトを作成でき、プロジェクトの管理者権限をユーザーコミュニティーの任意のメンバーに委任できます。クラスター管理者は、開発者が独自のプロジェクトを作成することも許可できます。

開発者および管理者は、CLI または Web コンソールを使用してプロジェクトと対話できます。

6.3. デフォルトプロジェクト

Azure Red Hat OpenShift にはデフォルトのプロジェクトが多数含まれ、openshift- で始まるプロジェクトはユーザーにとって最も重要になります。これらのプロジェクトは、Pod として実行されるマスターコンポーネントおよび他のインフラストラクチャーコンポーネントをホストします。Critical Pod アノテーション を持つこれらの namespace で作成される Pod は Critical (重要) あるとみなされ、kubelet による受付が保証されます。これらの namespace のマスターコンポーネント用に作成された Pod にはすでに Critical のマークが付けられます。

6.4. クラスターロールおよびバインディングの表示

oc CLI で oc describe コマンドを使用して、クラスターロールおよびバインディングを表示できます。

前提条件

  • oc CLI をインストールします。
  • クラスターロールおよびバインディングを表示するパーミッションを取得します。

手順

  1. クラスターロールおよびそれらの関連付けられたルールセットを表示するには、以下を実行します。
  2. 各種のロールにバインドされたユーザーおよびグループを示す、クラスターのロールバインディングの現在のセットを表示するには、以下を実行します。

6.5. ローカルのロールバインディングの表示

oc CLI で oc describe コマンドを使用して、ローカルロールおよびバインディングを表示できます。

前提条件

  • oc CLI をインストールします。
  • ローカルロールおよびバインディングを表示するパーミッションを取得します。

    • ローカルにバインドされた admin のデフォルトのクラスターロールを持つユーザーは、そのプロジェクトのロールおよびバインディングを表示し、管理できます。

手順

  1. 現在のプロジェクトの各種のロールにバインドされたユーザーおよびグループを示す、ローカルのロールバインディングの現在のセットを表示するには、以下を実行します。

    $ oc describe rolebinding.rbac
  2. 別のプロジェクトのローカルロールバインディングを表示するには、-n フラグをコマンドに追加します。

    $ oc describe rolebinding.rbac -n joe-project
    Name:         admin
    Labels:       <none>
    Annotations:  <none>
    Role:
      Kind:  ClusterRole
      Name:  admin
    Subjects:
      Kind  Name        Namespace
      ----  ----        ---------
      User  kube:admin
    
    
    Name:         system:deployers
    Labels:       <none>
    Annotations:  openshift.io/description:
                    Allows deploymentconfigs in this namespace to rollout pods in
                    this namespace.  It is auto-managed by a controller; remove
                    subjects to disa...
    Role:
      Kind:  ClusterRole
      Name:  system:deployer
    Subjects:
      Kind            Name      Namespace
      ----            ----      ---------
      ServiceAccount  deployer  joe-project
    
    
    Name:         system:image-builders
    Labels:       <none>
    Annotations:  openshift.io/description:
                    Allows builds in this namespace to push images to this
                    namespace.  It is auto-managed by a controller; remove subjects
                    to disable.
    Role:
      Kind:  ClusterRole
      Name:  system:image-builder
    Subjects:
      Kind            Name     Namespace
      ----            ----     ---------
      ServiceAccount  builder  joe-project
    
    
    Name:         system:image-pullers
    Labels:       <none>
    Annotations:  openshift.io/description:
                    Allows all pods in this namespace to pull images from this
                    namespace.  It is auto-managed by a controller; remove subjects
                    to disable.
    Role:
      Kind:  ClusterRole
      Name:  system:image-puller
    Subjects:
      Kind   Name                                Namespace
      ----   ----                                ---------
      Group  system:serviceaccounts:joe-project

6.6. ロールのユーザーへの追加

oc adm 管理者 CLI を使用してロールおよびバインディングを管理できます。

ロールをユーザーまたはグループにバインドするか、または追加することにより、そのロールによって付与されるアクセスがそのユーザーまたはグループに付与されます。oc adm policy コマンドを使用して、ロールのユーザーおよびグループへの追加、またはユーザーおよびグループからの削除を行うことができます。

デフォルトのクラスターロールのすべてを、プロジェクト内のローカルユーザーまたはグループにバインドできます。

手順

  1. ロールを特定プロジェクトのユーザーに追加します。

    $ oc adm policy add-role-to-user <role> <user> -n <project>

    たとえば、以下を実行して admin ロールを joe プロジェクトの alice ユーザーに追加できます。

    $ oc adm policy add-role-to-user admin alice -n joe
  2. 出力でローカルロールバインディングを確認し、追加の内容を確認します。

    $ oc describe rolebinding.rbac -n <project>

    たとえば、joe プロジェクトのローカルロールバインディングを表示するには、以下を実行します。

    $ oc describe rolebinding.rbac -n joe
    Name:         admin
    Labels:       <none>
    Annotations:  <none>
    Role:
      Kind:  ClusterRole
      Name:  admin
    Subjects:
      Kind  Name        Namespace
      ----  ----        ---------
      User  kube:admin
    
    
    Name:         admin-0
    Labels:       <none>
    Annotations:  <none>
    Role:
      Kind:  ClusterRole
      Name:  admin
    Subjects:
      Kind  Name   Namespace
      ----  ----   ---------
      User  alice 1
    
    
    Name:         system:deployers
    Labels:       <none>
    Annotations:  openshift.io/description:
                    Allows deploymentconfigs in this namespace to rollout pods in
                    this namespace.  It is auto-managed by a controller; remove
                    subjects to disa...
    Role:
      Kind:  ClusterRole
      Name:  system:deployer
    Subjects:
      Kind            Name      Namespace
      ----            ----      ---------
      ServiceAccount  deployer  joe
    
    
    Name:         system:image-builders
    Labels:       <none>
    Annotations:  openshift.io/description:
                    Allows builds in this namespace to push images to this
                    namespace.  It is auto-managed by a controller; remove subjects
                    to disable.
    Role:
      Kind:  ClusterRole
      Name:  system:image-builder
    Subjects:
      Kind            Name     Namespace
      ----            ----     ---------
      ServiceAccount  builder  joe
    
    
    Name:         system:image-pullers
    Labels:       <none>
    Annotations:  openshift.io/description:
                    Allows all pods in this namespace to pull images from this
                    namespace.  It is auto-managed by a controller; remove subjects
                    to disable.
    Role:
      Kind:  ClusterRole
      Name:  system:image-puller
    Subjects:
      Kind   Name                                Namespace
      ----   ----                                ---------
      Group  system:serviceaccounts:joe
    1
    alice ユーザーが admins RoleBinding に追加されています。

6.7. ローカルロールバインディングのコマンド

以下の操作を使用し、ローカルのロールバインディングでのユーザーまたはグループの関連付けられたロールを管理する際に、プロジェクトは -n フラグで指定できます。これが指定されていない場合には、現在のプロジェクトが使用されます。

ローカル RBAC 管理に以下のコマンドを使用できます。

表6.1 ローカルのロールバインディング操作

コマンド説明

$ oc adm policy who-can <verb> <resource>

リソースに対してアクションを実行できるユーザーを示します。

$ oc adm policy add-role-to-user <role> <username>

指定されたロールを現在のプロジェクトの指定ユーザーにバインドします。

$ oc adm policy remove-role-from-user <role> <username>

現在のプロジェクトの指定ユーザーから指定されたロールを削除します。

$ oc adm policy remove-user <username>

現在のプロジェクトの指定ユーザーとそれらのロールのすべてを削除します。

$ oc adm policy add-role-to-group <role> <groupname>

指定されたロールを現在のプロジェクトの指定グループにバインドします。

$ oc adm policy remove-role-from-group <role> <groupname>

現在のプロジェクトの指定グループから指定されたロールを削除します。

$ oc adm policy remove-group <groupname>

現在のプロジェクトの指定グループとそれらのロールのすべてを削除します。

第7章 kubeadmin ユーザーの削除

7.1. kubeadmin ユーザー

Azure Red Hat OpenShift は、インストールプロセスの完了後にクラスター管理者 kubeadmin を作成します。

このユーザーには、cluster-admin ロールが自動的に適用され、このユーザーはクラスターの root ユーザーとしてみなされます。パスワードは動的に生成され、Azure Red Hat OpenShift 環境に対して一意です。インストールの完了後に、パスワードはインストールプログラムの出力で提供されます。以下は例になります。

INFO Install complete!
INFO Run 'export KUBECONFIG=<your working directory>/auth/kubeconfig' to manage the cluster with 'oc', the OpenShift CLI.
INFO The cluster is ready when 'oc login -u kubeadmin -p <provided>' succeeds (wait a few minutes).
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.demo1.openshift4-beta-abcorp.com
INFO Login to the console with user: kubeadmin, password: <provided>

7.2. kubeadmin ユーザーの削除

アイデンティティープロバイダーを定義し、新規 cluster-admin ユーザーを作成した後に、クラスターのセキュリティーを強化するために kubeadmin を削除できます。

警告

別のユーザーが cluster-admin になる前にこの手順を実行する場合、Azure Red Hat OpenShift は再インストールされる必要があります。このコマンドをやり直すことはできません。

前提条件

  • 1 つ以上のアイデンティティープロバイダーを設定しておく必要があります。
  • cluster-admin ロールをユーザーに追加しておく必要があります。
  • 管理者としてログインしている必要があります。

手順

  • kubeadmin シークレットを削除します。

    $ oc delete secrets kubeadmin -n kube-system

第8章 ユーザーエージェントの設定

8.1. ユーザーエージェントについて

Azure Red Hat OpenShift は、アプリケーション開発者の CLI が Azure Red Hat OpenShift API にアクセスすることを防ぐために使用できるユーザーエージェントを実装します。クライアントが特定のライブラリーやバイナリーファイルを使用する場合、それらのクライアントは Azure Red Hat OpenShift API にアクセスできません。

Azure Red Hat OpenShift CLI のユーザーエージェントは、Azure Red Hat OpenShift 内の値のセットで構築します。

<command>/<version> (<platform>/<architecture>) <client>/<git_commit>

たとえば、以下の場合を考慮しましょう。

  • <command> = oc
  • <version> = クライアントのバージョン。(例: v4.3.0)。/api で Kubernetes API に対して行われる要求が Kubernetes のバージョンを受信し、/oapi で Azure Red Hat OpenShift API に対して行われる要求が Azure Red Hat OpenShift のバージョン (oc version によって指定される) を受信します。
  • <platform> = linux
  • <architecture> = amd64
  • <client> = openshift または kubernetes。 要求が /api で Kubernetes API に対して行われるか、/oapi で Azure Red Hat OpenShift API に対して行われるかによって決まります。
  • <git_commit> = クライアントバージョンの Git コミット (例: f034127)

上記の場合、ユーザーエージェントは以下のようになります。

oc/v3.3.0 (linux/amd64) openshift/f034127

8.2. ユーザーエージェントの設定

管理者は、マスター設定の userAgentMatching 設定を使用してクライアントが API にアクセスできないようにすることができます。

手順

  • マスター設定ファイルを、ユーザーエージェント設定を組み込むように変更します。たとえば、以下のユーザーエージェントは Kubernetes 1.2 クライアントバイナリー、OKD 1.1.3 バイナリー、および POST および PUT httpVerbs を拒否します。

    policyConfig:
      userAgentMatchingConfig:
        defaultRejectionMessage: "Your client is too old.  Go to https://example.org to update it."
        deniedClients:
        - regex: '\w+/v(?:(?:1\.1\.1)|(?:1\.0\.1)) \(.+/.+\) openshift/\w{7}'
        - regex: '\w+/v(?:1\.1\.3) \(.+/.+\) openshift/\w{7}'
          httpVerbs:
          - POST
          - PUT
        - regex: '\w+/v1\.2\.0 \(.+/.+\) kubernetes/\w{7}'
          httpVerbs:
          - POST
          - PUT
        requiredClients: null

    以下の例は、予想されるクライアントに一致しないクライアントを拒否します。

    policyConfig:
      userAgentMatchingConfig:
        defaultRejectionMessage: "Your client is too old.  Go to https://example.org to update it."
        deniedClients: []
        requiredClients:
        - regex: '\w+/v1\.1\.3 \(.+/.+\) openshift/\w{7}'
        - regex: '\w+/v1\.2\.0 \(.+/.+\) kubernetes/\w{7}'
          httpVerbs:
          - POST
          - PUT

第9章 サービスアカウントの概要および作成

9.1. サービスアカウントの概要

サービスアカウントは、コンポーネントが API に直接アクセスできるようにする Azure Red Hat OpenShift アカウントです。サービスアカウントは各プロジェクトに存在する API オブジェクトです。サービスアカウントは、通常ユーザーの認証情報を共有せずに API アクセスを制御する柔軟な方法を提供します。

Azure Red Hat OpenShift CLI または Web コンソールを使用する場合、API トークンは API に対する認証を行います。コンポーネントをサービスアカウントに関連付け、通常ユーザーの認証情報を使用せずにそれらが API にアクセスできるようにします。

各サービスアカウントのユーザー名は、そのプロジェクトおよび名前から派生します。

system:serviceaccount:<project>:<name>

すべてのサービスアカウントは以下の 2 つのグループのメンバーでもあります。

system:serviceaccounts
システムのすべてのサービスアカウントが含まれます。
system:serviceaccounts:<project>
指定されたプロジェクトのすべてのサービスアカウントが含まれます。

各サービスのアカウントには、2 つのシークレットが自動的に含まれます。

  • API トークン
  • OpenShift Container レジストリーの認証情報

生成される API トークンとレジストリーの認証情報は期限切れになることはありませんが、シークレットを削除することで取り消すことができます。シークレットが削除されると、新規のシークレットが自動生成され、これに置き換わります。

9.2. サービスアカウントの作成

サービスアカウントをプロジェクトで作成し、これをロールにバインドすることでパーミッションを付与できます。

手順

  1. オプション: サービスアカウントを現在のプロジェクトで表示するには、以下を実行します。

    $ oc get sa
    
    NAME       SECRETS   AGE
    builder    2         2d
    default    2         2d
    deployer   2         2d
  2. 新規サービスアカウントを現在のプロジェクトで作成するには、以下を実行します。

    $ oc create sa <service_account_name> 1
    
    serviceaccount "robot" created
    1
    別のプロジェクトでサービスアカウントを作成するには、-n <project_name> を指定します。
  3. オプション: サービスアカウントのシークレットを表示します。

    $ oc describe sa robot
    Name:		robot
    Namespace:	project1
    Labels:		<none>
    Annotations:	<none>
    
    Image pull secrets:	robot-dockercfg-qzbhb
    
    Mountable secrets: 	robot-token-f4khf
                       	robot-dockercfg-qzbhb
    
    Tokens:            	robot-token-f4khf
                       	robot-token-z8h44

9.3. ロールをサービスアカウントに付与する例

ロールをサービスアカウントに付与する方法は、ロールを通常ユーザーアカウントに付与する方法と同じです。

  • 現在のプロジェクトのサービスアカウントを変更できます。たとえば、view ロールを top-secret プロジェクトの robot サービスアカウントに追加するには、以下を実行します。

    $ oc policy add-role-to-user view system:serviceaccount:top-secret:robot
  • アクセスをプロジェクトの特定のサービスアカウントに付与することもできます。たとえば、サービスアカウントが属するプロジェクトから、-z フラグを使用し、<serviceaccount_name> を指定します。

    $ oc policy add-role-to-user <role_name> -z <serviceaccount_name>
    重要

    プロジェクトの特定のサービスアカウントにアクセスを付与する必要がある場合には、-z フラグを使用します。このフラグを使用することにより、アクセスが指定されたサービスアカウントのみに付与することができます。

  • 別の namespace を変更するには、-n オプションを使用して、以下の例にあるように、適用先のプロジェクト namespace を指定します。

    • たとえば、すべてのプロジェクトのすべてのサービスアカウントが top-secret プロジェクトのリソースを表示できるようにするには、以下を実行します。

      $ oc policy add-role-to-group view system:serviceaccounts -n top-secret
    • managers プロジェクトのすべてのサービスアカウントが top-secret プロジェクトのリソースを編集できるようにするには、以下を実行します。

      $ oc policy add-role-to-group edit system:serviceaccounts:managers -n top-secret

第10章 アプリケーションでのサービスアカウントの使用

10.1. サービスアカウントの概要

サービスアカウントは、コンポーネントが API に直接アクセスできるようにする Azure Red Hat OpenShift アカウントです。サービスアカウントは各プロジェクトに存在する API オブジェクトです。サービスアカウントは、通常ユーザーの認証情報を共有せずに API アクセスを制御する柔軟な方法を提供します。

Azure Red Hat OpenShift CLI または Web コンソールを使用する場合、API トークンは API に対する認証を行います。コンポーネントをサービスアカウントに関連付け、通常ユーザーの認証情報を使用せずにそれらが API にアクセスできるようにします。

各サービスアカウントのユーザー名は、そのプロジェクトおよび名前から派生します。

system:serviceaccount:<project>:<name>

すべてのサービスアカウントは以下の 2 つのグループのメンバーでもあります。

system:serviceaccounts
システムのすべてのサービスアカウントが含まれます。
system:serviceaccounts:<project>
指定されたプロジェクトのすべてのサービスアカウントが含まれます。

各サービスのアカウントには、2 つのシークレットが自動的に含まれます。

  • API トークン
  • OpenShift Container レジストリーの認証情報

生成される API トークンとレジストリーの認証情報は期限切れになることはありませんが、シークレットを削除することで取り消すことができます。シークレットが削除されると、新規のシークレットが自動生成され、これに置き換わります。

10.2. デフォルトのサービスアカウント

Azure Red Hat OpenShift クラスターには、クラスター管理用のデフォルトのサービスアカウントが含まれ、各プロジェクトのサービスアカウントは追加で生成されます。

10.2.1. デフォルトのクラスターサービスアカウント

一部のインフラストラクチャーコントローラーは、サービスアカウント認証情報を使用して実行されます。以下のサービスアカウントは、サーバーの起動時に Azure Red Hat OpenShift インフラストラクチャープロジェクト (openshift-infra) に作成され、クラスター全体での以下のロールが付与されます。

サービスアカウント説明

replication-controller

system:replication-controller ロールが割り当てられます。

deployment-controller

system:deployment-controller ロールが割り当てられます。

build-controller

system:build-controller ロールが割り当てられます。さらに、build-controller サービスアカウントは、特権付きの ビルド Pod を作成するために特権付きセキュリティーコンテキストに組み込まれます。

10.2.2. デフォルトのプロジェクトサービスアカウントおよびロール

3 つのサービスアカウントが各プロジェクトで自動的に作成されます。

サービスアカウント使用法

builder

ビルド Pod で使用されます。これには system:image-builder ロールが付与されます。 このロールは、内部 Docker レジストリーを使用してイメージをプロジェクトのイメージストリームにプッシュすることを可能にします。

deployer

デプロイメント Pod で使用され、system:deployer ロールが付与されます。 このロールは、プロジェクトでレプリケーションコントローラーや Pod を表示したり、変更したりすることを可能にします。

default

別のサービスアカウントが指定されていない限り、その他すべての Pod を実行するために使用されます。

プロジェクトのすべてのサービスアカウントには system:image-puller ロールが付与されます。 このロールは、内部コンテナーイメージレジストリーを使用してイメージをイメージストリームからプルすることを可能にします。

10.3. サービスアカウントの作成

サービスアカウントをプロジェクトで作成し、これをロールにバインドすることでパーミッションを付与できます。

手順

  1. オプション: サービスアカウントを現在のプロジェクトで表示するには、以下を実行します。

    $ oc get sa
    
    NAME       SECRETS   AGE
    builder    2         2d
    default    2         2d
    deployer   2         2d
  2. 新規サービスアカウントを現在のプロジェクトで作成するには、以下を実行します。

    $ oc create sa <service_account_name> 1
    
    serviceaccount "robot" created
    1
    別のプロジェクトでサービスアカウントを作成するには、-n <project_name> を指定します。
  3. オプション: サービスアカウントのシークレットを表示します。

    $ oc describe sa robot
    Name:		robot
    Namespace:	project1
    Labels:		<none>
    Annotations:	<none>
    
    Image pull secrets:	robot-dockercfg-qzbhb
    
    Mountable secrets: 	robot-token-f4khf
                       	robot-dockercfg-qzbhb
    
    Tokens:            	robot-token-f4khf
                       	robot-token-z8h44

10.4. サービスアカウントの認証情報の外部での使用

サービスアカウントのトークンは、API に対して認証する必要のある外部アプリケーションに配布することができます。

イメージをプルするには、要求される imagestreams/layers に対する get 権限が、この認証済みのユーザーに割り当てられている必要があります。また、イメージをプッシュするには、認証済みのユーザーに、要求される imagestreams/layers に対する update 権限が割り当てられている必要があります。

デフォルトで、プロジェクトのすべてのサービスアカウントは同じプロジェクトの任意のイメージをプルする権限を持ち、builder サービスアカウントには同じプロジェクトの任意のイメージをプッシュする権限を持ちます。

手順

  1. サービスアカウントのトークンを表示します。

    $ oc describe secret <secret-name>

    以下は例になります。

    $ oc describe secret robot-token-uzkbh -n top-secret
    
    Name:		robot-token-uzkbh
    Labels:		<none>
    Annotations:	kubernetes.io/service-account.name=robot,kubernetes.io/service-account.uid=49f19e2e-16c6-11e5-afdc-3c970e4b7ffe
    
    Type:	kubernetes.io/service-account-token
    
    Data
    
    token:	eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
  2. 取得したトークンを使用してログインします。

    $ oc login --token=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
    
    Logged into "https://server:8443" as "system:serviceaccount:top-secret:robot" using the token provided.
    
    You don't have any projects. You can try to create a new project, by running
    
        $ oc new-project <projectname>
  3. サービスアカウントとしてログインしたことを確認します。

    $ oc whoami
    
    system:serviceaccount:top-secret:robot

第11章 サービスアカウントの OAuth クライアントとしての使用

11.1. OAuth クライアントとしてのサービスアカウント

サービスアカウントは、OAuth クライアントの制限されたフォームで使用できます。サービスアカウントは一部の基本ユーザー情報へのアクセスを許可するスコープのサブセットと、サービスアカウント自体の namespace 内のロールベースの権限のみを要求できます。

  • user:info
  • user:check-access
  • role:<any_role>:<serviceaccount_namespace>
  • role:<any_role>:<serviceaccount_namespace>:!

サービスアカウントを OAuth クライアントとして使用する場合:

  • client_idsystem:serviceaccount:<serviceaccount_namespace>:<serviceaccount_name> になります。
  • client_secret には、サービスアカウントの API トークンのいずれかを指定できます。以下は例になります。

    $ oc sa get-token <serviceaccount_name>
  • WWW-Authenticate チャレンジを取得するには、サービスアカウントの serviceaccounts.openshift.io/oauth-want-challenges アノテーションを true に設定します。
  • redirect_uri は、サービスアカウントのアノテーションに一致する必要があります。

11.1.1. OAuth クライアントとしてのサービスアカウントの URI のリダイレクト

アノテーションキーには、以下のようにプレフィックス serviceaccounts.openshift.io/oauth-redirecturi. または serviceaccounts.openshift.io/oauth-redirectreference. が含まれる必要があります。

serviceaccounts.openshift.io/oauth-redirecturi.<name>

最も単純なフォームでは、アノテーションは有効なリダイレクト URI を直接指定するために使用できます。以下は例になります。

"serviceaccounts.openshift.io/oauth-redirecturi.first":  "https://example.com"
"serviceaccounts.openshift.io/oauth-redirecturi.second": "https://other.com"

上記の例の first および second ポストフィックスは 2 つの有効なリダイレクト URI を分離するために使用されます。

さらに複雑な設定では、静的なリダイレクト URI のみでは不十分な場合があります。たとえば、ルートのすべての ingress が有効とみなされる必要があるかもしれません。この場合、serviceaccounts.openshift.io/oauth-redirectreference. プレフィックスを使用した動的なリダイレクト URI を使用できます。

以下は例になります。

"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"

このアノテーションの値にはシリアライズされた JSON データが含まれるため、これを拡張フォーマットで表示するとより容易になります。

{
  "kind": "OAuthRedirectReference",
  "apiVersion": "v1",
  "reference": {
    "kind": "Route",
    "name": "jenkins"
  }
}

ここでは、OAuthRedirectReference により jenkins という名前のルートを参照できます。そのため、そのルートのすべての ingress は有効とみなされます。OAuthRedirectReference の詳細な仕様は以下のようになります。

{
  "kind": "OAuthRedirectReference",
  "apiVersion": "v1",
  "reference": {
    "kind": ..., 1
    "name": ..., 2
    "group": ... 3
  }
}
1
kind は参照されているオブジェクトのタイプを参照します。現時点では、route のみがサポートされています。
2
name はオブジェクトの名前を参照します。このオブジェクトはサービスアカウントと同じ namespace にある必要があります。
3
group はオブジェクトのグループを参照します。ルートのグループは空の文字列であるため、これを空白のままにします。

アノテーションはどちらも、プレフィックスも組み合わせて、参照オブジェクトで提供されるデータを上書きできます。以下は例になります。

"serviceaccounts.openshift.io/oauth-redirecturi.first":  "custompath"
"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"

first ポストフィックスはアノテーションを関連付けるために使用されます。jenkins ルートに https://example.com の ingress がある場合に、https://example.com/custompath が有効とみなされますが、https://example.com は有効とみなされません。上書きデータを部分的に指定するためのフォーマットは以下のようになります。

タイプ構文

スキーム

"https://"

Hostname

"//website.com"

ポート

"//:8000"

パス

"examplepath"

注記

ホスト名の上書きを指定すると、参照されるオブジェクトのホスト名データが置き換わりますが、これは望ましい動作ではありません。

上記の構文のいずれの組み合わせも、以下のフォーマットを使って実行できます。

<scheme:>//<hostname><:port>/<path>

同じオブジェクトを複数回参照して、柔軟性を向上することができます。

"serviceaccounts.openshift.io/oauth-redirecturi.first":  "custompath"
"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
"serviceaccounts.openshift.io/oauth-redirecturi.second":  "//:8000"
"serviceaccounts.openshift.io/oauth-redirectreference.second": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"

jenkins という名前のルートに https://example.com の ingress がある場合には、https://example.com:8000https://example.com/custompath の両方が有効とみなされます。

必要な動作を得るために、静的で動的なアノテーションを同時に使用できます。

"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
"serviceaccounts.openshift.io/oauth-redirecturi.second": "https://other.com"

第12章 スコープトークン

12.1. トークンのスコープについて

スコープ付きトークンを作成して、パーミッションの一部を別のユーザーまたはサービスアカウントに委任できます。たとえば、プロジェクト管理者は Pod の作成権限を委任する必要があるかもしれません。

スコープ付きトークンは、指定されるユーザーを識別しますが、そのスコープによって特定のアクションに制限されるトークンです。cluster-admin ロールを持つユーザーのみがスコープ付きトークンを作成できます。

スコープは、トークンの一連のスコープを PolicyRules のセットに変換して評価されます。次に、要求がそれらのルールに対してマッチングされます。要求属性は、追加の認可検査のために「標準」の承認者に渡せるよう、スコープルールのいずれかに一致している必要があります。

12.1.1. ユーザースコープ

ユーザースコープでは、指定されたユーザーについての情報を取得することにフォーカスが置かれます。それらはインテントベースであるため、ルールは自動的に作成されます。

  • user:full: ユーザーのすべてのパーミッションによる API の完全な読み取り/書き込みアクセスを許可します。
  • user:info: 名前やグループなどのユーザーについての情報の読み取り専用アクセスを許可します。
  • user:check-access: self-localsubjectaccessreviews および self-subjectaccessreviews へのアクセスを許可します。これらは、要求オブジェクトの空のユーザーおよびグループを渡す変数です。
  • user:list-projects: ユーザーがアクセスできるプロジェクトを一覧表示するための読み取り専用アクセスを許可します。

12.1.2. ロールスコープ

ロールスコープにより、 namespace でフィルターされる指定ロールと同じレベルのアクセスを持たせることができます。

  • role:<cluster-role name>:<namespace or * for all>: 指定された namespace のみにあるクラスターロール (cluster-role) で指定されるルールにスコープを制限します。

    注記

    注意: これは、アクセスのエスカレートを防ぎます。ロールはシークレット、ロールバインディング、およびロールなどのリソースへのアクセスを許可しますが、このスコープはそれらのリソースへのアクセスを制限するのに役立ちます。これにより、予期しないエスカレーションを防ぐことができます。edit などのロールはエスカレートされるロールと見なされないことが多いですが、シークレットのアクセスを持つロールの場合はエスカレーションが生じます。

  • role:<cluster-role name>:<namespace or * for all>:!: bang (!) を含めることでこのスコープでアクセスのエスカレートを許可されますが、それ以外には上記の例と同様になります。

第13章 SCC (Security Context Constraints) の管理

13.1. SCC (Security Context Constraints) について

RBAC リソースがユーザーアクセスを制御するのと同じ方法で、管理者は SCC (Security Context Constraints) を使用して Pod のパーミッションを制御できます。これらのパーミッションには、コンテナーのコレクションである pod が実行できるアクションおよびそれがアクセスできるリソース情報が含まれます。SCC を使用して、Pod がシステムに受け入れられるために必要な Pod の実行についての条件の一覧を定義することができます。

法律上の通知

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.

このページには機械翻訳が使用されている場合があります (詳細はこちら)。