3.3. Keycloak CR の移行

Red Hat build of Keycloak は、以前に Red Hat Single Sign-On 7.6 で使用されていたのと同じデータベースインスタンスを使用できます。データベーススキーマは、Red Hat build of Keycloak が初めてデータベースに接続するときに自動的に移行されます。

Red Hat Single Sign-On 7.6 Operator では、外部データベース接続はシークレットを使用して設定していました。次に例を示します。

apiVersion: v1
kind: Secret
metadata:
  name: keycloak-db-secret
  namespace: keycloak
  labels:
    app: sso
stringData:
  POSTGRES_DATABASE:  kc-db-name
  POSTGRES_EXTERNAL_ADDRESS: my-postgres-hostname
  POSTGRES_EXTERNAL_PORT: 5432
  POSTGRES_USERNAME: user
  POSTGRES_PASSWORD: pass
type: Opaque

Red Hat build of Keycloak では、データベースは、シークレットとして参照される認証情報を使用して Keycloak CR に直接設定されます。次に例を示します。

apiVersion: k8s.keycloak.org/v2alpha1
kind: Keycloak
metadata:
  name: example-kc
spec:
  db:
    vendor: postgres
    host: my-postgres-hostname
    port: 5432
    usernameSecret:
      name: keycloak-db-secret
      key: username
    passwordSecret:
      name: keycloak-db-secret
      key: password
  ...

apiVersion: v1
kind: Secret
metadata:
  name: keycloak-db-secret
stringData:
  username: "user"
  password: "pass"
type: Opaque

Red Hat Single Sign-On 7.6 Operator では、デフォルトで、OpenShift CA によって生成された TLS シークレットを使用するようにサーバーが設定されていました。Red Hat build of Keycloak Operator では、実稼働環境のベストプラクティスを実現するために、TLS については何も前提を設けておらず、ユーザーが独自の TLS 証明書とキーペアを提供する必要があります。次に例を示します。

apiVersion: k8s.keycloak.org/v2alpha1
kind: Keycloak
metadata:
  name: example-kc
spec:
  http:
    tlsSecret: example-tls-secret
  ...

tlsSecret で参照されるシークレットの形式には、標準の Kubernetes TLS シークレット (kubernetes.io/tls) タイプを使用する必要があります。

Red Hat Single Sign-On 7.6 Operator は、デフォルトで、ルートで再暗号化 TLS Termination ストラテジーを使用していました。Red Hat build of Keycloak Operator は、デフォルトでパススルーストラテジーを使用します。また、Red Hat Single Sign-On 7.6 Operator は、TLS Termination の設定をサポートしていました。Red Hat build of Keycloak Operator は、現在のリリースでは TLS Termination をサポートしていません。

デフォルトの Operator 管理のルートが必要な TLS 設定を満たさない場合は、ユーザーがカスタムルートを作成し、デフォルトのルートを次のようにして無効にする必要があります。

apiVersion: k8s.keycloak.org/v2alpha1
kind: Keycloak
metadata:
  name: example-kc
spec:
  ingress:
    enabled: false
  ...

Red Hat build of Keycloak Operator では、ベストプラクティスを反映し、イミュータブルコンテナーをサポートするために、Keycloak CR でのエクステンションの指定がサポートされていません。エクステンションをデプロイするには、最適化されたカスタムイメージをビルドする必要があります。Keycloak CR には、Red Hat build of Keycloak イメージを指定するための専用フィールドが含まれるようになりました。次に例を示します。

apiVersion: k8s.keycloak.org/v2alpha1
kind: Keycloak
metadata:
  name: example-kc
spec:
  image: quay.io/my-company/my-keycloak:latest
  ...

Red Hat Single Sign-On 7.6 Operator は、サーバーのアップグレード実行時の再作成およびローリングストラテジーをサポートしていました。このアプローチは現実的ではありませんでした。Red Hat Single Sign-On 7.6 Operator がアップグレードとデータベース移行を実行する前にデプロイメントをスケールダウンするかどうかは、ユーザーが選択する必要がありました。ローリングストラテジーがいつ安全に使用できるかは、ユーザーには明らかではありませんでした。

したがって、このオプションは Red Hat build of Keycloak Operator では削除され、再作成ストラテジーは常に暗黙的に実行されるようになりました。これにより、新しいサーバーコンテナーイメージで Pod を作成する前にデプロイメント全体がスケールダウンされ、単一のサーバーバージョンのみがデータベースにアクセスできるようになります。

Red Hat build of Keycloak は、OpenShift プローブによって使用される単純なヘルスエンドポイントをデフォルトで公開するようにサーバーを設定します。エンドポイントはデプロイメントに関するセキュリティー上の機密データを公開しませんが、エンドポイントには認証なしでアクセスできます。代替策として、<your-server-context-root>/health エンドポイントをカスタムルートでブロックできます。

以下に例を示します。

Red Hat Single Sign-On 7.6 Operator は、ボリュームなどのデプロイメント設定用の複数の低レベルフィールドを公開していました。Red Hat build of Keycloak Operator は事前設定される部分が多く、これらのフィールドのほとんどは公開されません。ただし、podTemplate として指定されたデプロイメントフィールドを設定することは可能です。次に例を示します。

apiVersion: k8s.keycloak.org/v2alpha1
kind: Keycloak
metadata:
  name: example-kc
spec:
  unsupported:
    podTemplate:
      metadata:
        labels:
          foo: "bar"
      spec:
        containers:
          - volumeMounts:
              - name: test-volume
                mountPath: /mnt/test
        volumes:
          - name: test-volume
            secret:
              secretName: test-secret
  ...

Red Hat Single Sign-On 7.6 Operator では、Red Hat Single Sign-On 7.6 の外部インスタンスへの接続がサポートされていました。Red Hat build of Keycloak Operator では、たとえば、クライアント CR を使用して既存のレルム内にクライアントを作成することは、サポートされなくなりました。

Red Hat Single Sign-On 7.6 で Horizontal Pod Autoscaler (HPA) を使用するには、Keycloak CR の disableReplicasSyncing: true フィールドを設定し、サーバーの StatefulSet をスケーリングする必要がありました。これは不要になりました。Red Hat build of Keycloak Operator の Keycloak CR は、HPA によって直接スケーリングできるためです。