第2章 基本的な Red Hat build of Keycloak デプロイメント
2.1. 基本的な Red Hat build of Keycloak デプロイメントの実行
この章では、Operator を使用して OpenShift 上で基本的な Red Hat build of Keycloak デプロイメントを実行する方法を説明します。
2.1.1. デプロイメントの準備
Red Hat build of Keycloak Operator がインストールされ、クラスター namespace で実行されたら、他のデプロイメントの要件をセットアップできます。
- データベース
- ホスト名
- TLS 証明書と関連する鍵
2.1.1.1. データベース
データベースが利用可能であり、Red Hat build of Keycloak がインストールされているクラスター namespace からアクセスできる必要があります。サポートされているデータベースのリストについては、データベースの設定 を参照してください。Red Hat build of Keycloak Operator はデータベースを管理しないため、管理者がプロビジョニングする必要があります。クラウドプロバイダーのサービスを確認するか、データベース Operator の使用を検討してください。
開発目的には、一時的な PostgreSQL Pod インストールを使用できます。プロビジョニングするには、以下の方法に従います。
YAML ファイル example-postgres.yaml
を作成します。
apiVersion: apps/v1 kind: StatefulSet metadata: name: postgresql-db spec: serviceName: postgresql-db-service selector: matchLabels: app: postgresql-db replicas: 1 template: metadata: labels: app: postgresql-db spec: containers: - name: postgresql-db image: postgres:15 volumeMounts: - mountPath: /data name: cache-volume env: - name: POSTGRES_USER value: testuser - name: POSTGRES_PASSWORD value: testpassword - name: PGDATA value: /data/pgdata - name: POSTGRES_DB value: keycloak volumes: - name: cache-volume emptyDir: {} --- apiVersion: v1 kind: Service metadata: name: postgres-db spec: selector: app: postgresql-db type: LoadBalancer ports: - port: 5432 targetPort: 5432
変更を適用します。
oc apply -f example-postgres.yaml
2.1.1.2. ホスト名
実稼働環境に対応したインストールの場合、Red Hat build of Keycloak に接続するために使用できるホスト名が必要です。利用可能な設定については、ホスト名の設定 を参照してください。
この章では開発目的で test.keycloak.org
を使用します。
OpenShift 上で実行する場合は、Ingress が有効で、spec.ingress.classname が openshift-default に設定されている場合、Keycloak CR の spec.hostname.hostname を未設定のままにしておくことができます。Operator は、明示的なホストのない OpenShift ルートによって作成されるホスト名と同様に、保存されたバージョンの CR にデフォルトのホスト名 ingress-namespace.appsDomain を割り当てます。appsDomain を変更した場合、または何らかの理由で別のホスト名が必要な場合は、Keycloak CR を更新してください。
hostname-admin または非推奨の
を設定すると、ingress を有効にしても、管理者アクセス専用の ingress が作成されません。別個のホスト名を使用した管理者アクセスは通常、アクセス制限があることが予想されますが、現在 Keycloak CR 経由では表現できません。また、デフォルトの Ingress は管理者エンドポイントへのアクセスを阻止しないため、管理者エンドポイントに別のホスト名がある場合は、Keycloak CR を介した ingress 処理を有効にしないといけない場合があります。
hostname-admin
-url
2.1.1.3. TLS 証明書と鍵
証明書と鍵を取得するには、認証局に問い合わせてください。
開発目的の場合は、次のコマンドを入力して自己署名証明書を取得できます。
openssl req -subj '/CN=test.keycloak.org/O=Test Keycloak./C=US' -newkey rsa:2048 -nodes -keyout key.pem -x509 -days 365 -out certificate.pem
次のコマンドを入力して、クラスター namespace に証明書をシークレットとしてインストールする必要があります。
oc create secret tls example-tls-secret --cert certificate.pem --key key.pem
2.1.2. Red Hat build of Keycloak のデプロイ
Red Hat build of Keycloak をデプロイするには、Keycloak カスタムリソース定義 (CRD) に基づいてカスタムリソース (CR) を作成します。
データベース認証情報を別のシークレットに保存することを検討してください。次のコマンドを入力します。
oc create secret generic keycloak-db-secret \ --from-literal=username=[your_database_username] \ --from-literal=password=[your_database_password]
Keycloak CRD を使用して、いくつかのフィールドをカスタマイズできます。基本的なデプロイメントの場合は、次のアプローチに従うことができます。
YAML ファイル example-kc.yaml
を作成します。
apiVersion: k8s.keycloak.org/v2alpha1 kind: Keycloak metadata: name: example-kc spec: instances: 1 db: vendor: postgres host: postgres-db usernameSecret: name: keycloak-db-secret key: username passwordSecret: name: keycloak-db-secret key: password http: tlsSecret: example-tls-secret hostname: hostname: test.keycloak.org proxy: headers: xforwarded # double check your reverse proxy sets and overwrites the X-Forwarded-* headers
変更を適用します。
oc apply -f example-kc.yaml
Red Hat build of Keycloak インスタンスがクラスターにプロビジョニングされていることを確認するには、次のコマンドを入力して、作成された CR のステータスを確認します。
oc get keycloaks/example-kc -o go-template='{{range .status.conditions}}CONDITION: {{.type}}{{"\n"}} STATUS: {{.status}}{{"\n"}} MESSAGE: {{.message}}{{"\n"}}{{end}}'
デプロイメントの準備ができたら、次のような出力を探します。
CONDITION: Ready STATUS: true MESSAGE: CONDITION: HasErrors STATUS: false MESSAGE: CONDITION: RollingUpdate STATUS: false MESSAGE:
2.1.3. Red Hat build of Keycloak デプロイメントへのアクセス
Red Hat build of Keycloak デプロイメントは、基本的な Ingress を通じて公開され、指定されたホスト名を通じてアクセス可能になります。複数のデフォルトの IngressClass インスタンスを含むインストールの場合、または OpenShift 4.12 以降で実行する場合は、className
プロパティーを持つ ingress
仕様を目的のクラス名に設定して、ingressClassName を指定する必要があります。
YAML ファイル example-kc.yaml
を編集します。
apiVersion: k8s.keycloak.org/v2alpha1 kind: Keycloak metadata: name: example-kc spec: ... ingress: className: openshift-default
デフォルトの Ingress がユースケースに適合しない場合は、enabled
プロパティーを持つ ingress
仕様を false
値に設定して無効にします。
YAML ファイル example-kc.yaml
を編集します。
apiVersion: k8s.keycloak.org/v2alpha1 kind: Keycloak metadata: name: example-kc spec: ... ingress: enabled: false
変更を適用します。
oc apply -f example-kc.yaml
サービス <keycloak-cr-name>-service
を参照する代替 Ingress リソースを提供できます。
デバッグと開発の目的では、ポート転送を使用して Red Hat build of Keycloak サービスに直接接続することを検討してください。たとえば、次のコマンドを入力します。
oc port-forward service/example-kc-service 8443:8443
2.1.3.1. Ingress コントローラーに一致するリバースプロキシー設定の指定
Operator は、Forwarded
ヘッダーや X-Forwarded-*
ヘッダーなど、サーバーが受け入れるリバースプロキシーヘッダーの設定をサポートしています。
Ingress 実装で Forwarded
または X-Forwarded-*
ヘッダーのいずれかを設定して上書きする場合は、次のようにすることで、それを Keycloak CR に反映できます。
apiVersion: k8s.keycloak.org/v2alpha1 kind: Keycloak metadata: name: example-kc spec: ... proxy: headers: forwarded|xforwarded
proxy.headers
フィールドが指定されていない場合、Operator はデフォルトで proxy=passthrough
を暗黙的に設定して、従来の動作にフォールバックします。これにより、サーバーログに非推奨の警告が記録されます。このフォールバックは今後のリリースで削除される予定です。
proxy.headers
フィールドを使用する場合は、Ingress によって Forwarded
ヘッダーまたは X-Forwarded-*
ヘッダーが適切に設定および上書きされることを確認してください。これらのヘッダーを設定するには、Ingress コントローラーのドキュメントを参照してください。パススルー TLS は Ingress によるリクエストヘッダーの変更を許可しないため、再暗号化またはエッジ TLS 終端用にコントローラーを設定することを検討してください。設定を誤ると、Red Hat build of Keycloak がセキュリティー上の脆弱性にさらされることになります。
詳細は、リバースプロキシーの使用 ガイドを参照してください。
2.1.4. 管理コンソールへのアクセス
Red Hat build of Keycloak をデプロイする場合、Operator は任意の初期管理者の username
と password
を生成し、それらの認証情報を CR と同じ namespace に basic-auth シークレットオブジェクトとして保存します。
実稼働を開始する前に、デフォルトの管理者の認証情報を変更し、Red Hat build of Keycloak で MFA を有効にしてください。
初期の管理者認証情報を取得するには、シークレットを読み取ってデコードする必要があります。シークレット名は、Keycloak CR 名に固定接尾辞 -initial-admin
を加えたものから導出されます。example-kc
CR のユーザー名とパスワードを取得するには、次のコマンドを入力します。
oc get secret example-kc-initial-admin -o jsonpath='{.data.username}' | base64 --decode oc get secret example-kc-initial-admin -o jsonpath='{.data.password}' | base64 --decode
これらの認証情報を使用して、管理コンソールまたは管理 REST API にアクセスできます。