5.3. 手順
- Data Grid Operator をインストールします。
Data Grid クラスターにアクセスするための認証情報を設定します。
Red Hat build of Keycloak が Data Grid クラスターで認証できるようにするには、この認証情報が必要です。次の
identities.yamlファイルで、管理者権限を持つユーザー名とパスワードを設定します。credentials: - username: developer password: strong-password roles: - adminidentities.yamlは、次のいずれかの方法でシークレットに設定できます。Kubernetes リソースとして:
認証情報シークレット
apiVersion: v1 kind: Secret type: Opaque metadata: name: connect-secret namespace: keycloak data: identities.yaml: Y3JlZGVudGlhbHM6CiAgLSB1c2VybmFtZTogZGV2ZWxvcGVyCiAgICBwYXNzd29yZDogc3Ryb25nLXBhc3N3b3JkCiAgICByb2xlczoKICAgICAgLSBhZG1pbgo= 1- 1
- Base64 でエンコードした上記の例の
identities.yaml。
CLI の使用
oc create secret generic connect-secret --from-file=identities.yaml
詳細は、認証の設定 ドキュメントを参照してください。
これらのコマンドは両方の OpenShift クラスターで実行する必要があります。
サービスアカウントを作成します。
クラスター間の接続を確立するには、サービスアカウントが必要です。Data Grid Operator は、これを使用してリモートサイトからネットワーク設定を検査し、それに応じてローカル Data Grid クラスターを設定します。
詳細は、マネージドのクロスサイトレプリケーション ドキュメントを参照してください。
次のように
service-account-tokenシークレットタイプを作成します。同じ YAML ファイルを両方の OpenShift クラスターで使用できます。xsite-sa-secret-token.yaml
apiVersion: v1 kind: Secret metadata: name: ispn-xsite-sa-token 1 annotations: kubernetes.io/service-account.name: "xsite-sa" 2 type: kubernetes.io/service-account-token
サービスアカウントを作成し、両方の OpenShift クラスターでアクセストークンを生成します。
Site-Aでサービスアカウントを作成するoc create sa -n keycloak xsite-sa oc policy add-role-to-user view -n keycloak -z xsite-sa oc create -f xsite-sa-secret-token.yaml oc get secrets ispn-xsite-sa-token -o jsonpath="{.data.token}" | base64 -d > Site-A-token.txtSite-Bでサービスアカウントを作成するoc create sa -n keycloak xsite-sa oc policy add-role-to-user view -n keycloak -z xsite-sa oc create -f xsite-sa-secret-token.yaml oc get secrets ispn-xsite-sa-token -o jsonpath="{.data.token}" | base64 -d > Site-B-token.txt次に、
Site-AからSite-Bにトークンをデプロイしてから、その逆を行います。Site-BのトークンをSite-Aにデプロイするoc create secret generic -n keycloak xsite-token-secret \ --from-literal=token="$(cat Site-B-token.txt)"
Site-AのトークンをSite-Bにデプロイするoc create secret generic -n keycloak xsite-token-secret \ --from-literal=token="$(cat Site-A-token.txt)"
TLS シークレットを作成します。
この章では、Data Grid でクロスサイト通信に OpenShift ルートを使用します。この OpenShift ルートは、TLS の SNI 拡張を使用してトラフィックを正しい Pod に送信します。これを実現するために、JGroups は TLS ソケットを使用します。これには、正しい証明書を備えたキーストアとトラストストアが必要です。
詳細は、クロスサイト接続のセキュリティー保護 ドキュメントまたはこちらの Red Hat Developer Guide を参照してください。
キーストアとトラストストアは、OpenShift シークレットでアップロードします。シークレットには、ファイルの内容、ファイルにアクセスするためのパスワード、およびストアのタイプを含めます。証明書とストアを作成する手順は、この章では説明しません。
キーストアをシークレットとしてアップロードするには、次のコマンドを使用します。
キーストアのデプロイ
oc -n keycloak create secret generic xsite-keystore-secret \ --from-file=keystore.p12="./certs/keystore.p12" \ 1 --from-literal=password=secret \ 2 --from-literal=type=pkcs12 3
トラストストアをシークレットとしてアップロードするには、次のコマンドを使用します。
トラストストアのデプロイ
oc -n keycloak create secret generic xsite-truststore-secret \ --from-file=truststore.p12="./certs/truststore.p12" \ 1 --from-literal=password=caSecret \ 2 --from-literal=type=pkcs12 3注記キーストアとトラストストアは、両方の OpenShift クラスターにアップロードする必要があります。
クロスサイトを有効にして Data Grid のクラスターを作成する
クロスサイトの設定 ドキュメントに、上記の手順を含め、クロスサイトを有効にして Data Grid クラスターを作成および設定する方法に関するすべての情報が記載されています。
この章では、上記の手順のコマンドによって作成された認証情報、トークン、および TLS キーストア/トラストストアを使用した基本的な例を示します。
Site-AのInfinispanCRapiVersion: infinispan.org/v1 kind: Infinispan metadata: name: infinispan 1 namespace: keycloak annotations: infinispan.org/monitoring: 'true' 2 spec: replicas: 3 jmx: enabled: true security: endpointSecretName: connect-secret 3 service: type: DataGrid sites: local: name: site-a 4 expose: type: Route 5 maxRelayNodes: 128 encryption: transportKeyStore: secretName: xsite-keystore-secret 6 alias: xsite 7 filename: keystore.p12 8 routerKeyStore: secretName: xsite-keystore-secret 9 alias: xsite 10 filename: keystore.p12 11 trustStore: secretName: xsite-truststore-secret 12 filename: truststore.p12 13 locations: - name: site-b 14 clusterName: infinispan namespace: keycloak 15 url: openshift://api.site-b 16 secretName: xsite-token-secret 17
- 1
- クラスター名。
- 2
- Prometheus によるクラスターの監視を許可します。
- 3
- カスタムの認証情報を使用する場合は、ここでシークレット名を設定します。
- 4
- ローカルサイトの名前。この場合は
Site-Aです。 - 5
- OpenShift ルートを使用したクロスサイト接続の公開。
- 6 9
- 前のステップで定義したキーストアが存在するシークレット名。
- 7 10
- キーストア内の証明書のエイリアス。
- 8 11
- 前のステップで定義したキーストアの秘密鍵 (ファイル名)。
- 12
- 前のステップで定義したトラストストアが存在するシークレット名。
- 13
- 前のステップで定義したキーストアのトラストストアキー (ファイル名)。
- 14
- リモートサイトの名前 (この場合は
Site-B)。 - 15
- リモートサイトの Data Grid クラスターの namespace。
- 16
- リモートサイトの OpenShift API URL。
- 17
- リモートサイトで認証するためのアクセストークンを含むシークレット。
Site-BのInfinispanCR も上記と同様です。ポイント 4、11、13 の違いに注意してください。Site-BのInfinispanCRapiVersion: infinispan.org/v1 kind: Infinispan metadata: name: infinispan 1 namespace: keycloak annotations: infinispan.org/monitoring: 'true' 2 spec: replicas: 3 jmx: enabled: true security: endpointSecretName: connect-secret 3 service: type: DataGrid sites: local: name: site-b 4 expose: type: Route 5 maxRelayNodes: 128 encryption: transportKeyStore: secretName: xsite-keystore-secret 6 alias: xsite 7 filename: keystore.p12 8 routerKeyStore: secretName: xsite-keystore-secret 9 alias: xsite 10 filename: keystore.p12 11 trustStore: secretName: xsite-truststore-secret 12 filename: truststore.p12 13 locations: - name: site-a 14 clusterName: infinispan namespace: keycloak 15 url: openshift://api.site-a 16 secretName: xsite-token-secret 17
Red Hat build of Keycloak 用のキャッシュを作成します。
Red Hat build of Keycloak では、
actionTokens、authenticationSessions、loginFailures、workのキャッシュが存在している必要があります。Data Grid Cache CR を使用すると、Data Grid クラスターにキャッシュをデプロイできます。クロスサイトのドキュメント に記載されているように、クロスサイトはキャッシュごとに有効にする必要があります。このドキュメントには、この章で使用するオプションの詳細が記載されています。次の例は、
Site-AのCacheCR を示しています。-
Site-Aで、上記の各キャッシュに対して次の内容のCacheCR を作成します。これはauthenticationSessionsキャッシュの例です。
apiVersion: infinispan.org/v2alpha1 kind: Cache metadata: name: authenticationsessions namespace: keycloak spec: clusterName: infinispan name: authenticationSessions template: |- distributedCache: mode: "SYNC" owners: "2" statistics: "true" remoteTimeout: "5000" encoding: media-type: "application/x-protostream" locking: acquireTimeout: "4000" transaction: mode: "NON_XA" 1 locking: "PESSIMISTIC" 2 stateTransfer: chunkSize: "16" backups: site-b: 3 backup: strategy: "SYNC" 4 timeout: "4500" 5 failurePolicy: "FAIL" 6 stateTransfer: chunkSize: "16"上記の例は、最善のデータ整合性を実現するために推奨される設定です。
背景情報
アクティブ/アクティブ設定では、両方のサイトでエントリーが同時に変更されるため、デッドロックが発生する可能性があります。
transaction.mode: NON_XAでは、そのようになった場合にデータの整合性を保ちながらトランザクションがロールバックされます。この場合、backup.failurePolicy: FAILを設定する必要があります。トランザクションを安全にロールバックするためのエラーが出力されます。この状況が発生すると、Red Hat build of Keycloak は再試行を試みます。transaction.locking: PESSIMISTICは唯一サポートされているロックモードです。OPTIMISTICはネットワークコストが高いため推奨されません。同じ設定により、一方のサイトにアクセスできない間にもう一方のサイトが更新されることも防止されます。backup.strategy: SYNCでは、Red Hat build of Keycloak のリクエストが完了したときに、データが他のサイトで表示および保存されます。注記locking.acquireTimeoutを短くすると、デッドロックシナリオでフェイルファストを実行できます。backup.timeoutは必ずlocking.acquireTimeoutよりも大きくなければなりません。Site-Bの場合、上図のポイント 3 に示されているbackups.<name>を除き、CacheCR は同じようになります。Site-Bの authenticationSessionsCacheCRapiVersion: infinispan.org/v2alpha1 kind: Cache metadata: name: authenticationsessions namespace: keycloak spec: clusterName: infinispan name: authenticationSessions template: |- distributedCache: mode: "SYNC" owners: "2" statistics: "true" remoteTimeout: "5000" encoding: media-type: "application/x-protostream" locking: acquireTimeout: "4000" transaction: mode: "NON_XA" 1 locking: "PESSIMISTIC" 2 stateTransfer: chunkSize: "16" backups: site-a: 3 backup: strategy: "SYNC" 4 timeout: "4500" 5 failurePolicy: "FAIL" 6 stateTransfer: chunkSize: "16"-
