Keycloak Operator with external DB as a default

[Sebastian Łaskawiec]

Dear all,

As you probably know, Keycloak Operator spins a Postgresql database up for Keycloak Pods. After several discussions with Stian, we came to a conclusion that we (as Keycloak Team) can not reliably host and maintain it. None of us is a database expert and managing things like database backup, restore, HA configuration maintenance is far beyond our knowledge. Our proposal is to remove this functionality from future versions.

During the next couple of days/weeks, I'll write up a Design Document and create proper JIRAs. For the time being, I'd like to gather the first round of feedback from the community.

Currently Keycloak Operator supports external Postgresql database [1]. This setup requires creating a Secret with database credentials (described in the manual). This approach needs to be enhanced as it's a bit too complicated to be used as a default option. I propose to modify our Keycloak CR to contain a mandatory field with explicit external database credentials Secret. It also goes without saying, this is a big behavioral change and requires increasing api version. Here's a proposed Keycloak CR example along with a credential Secret:

# moved from keycloak.org/v1alpha1 to keycloak.org/v1alpha2

apiVersion: keycloak.org/v1alpha2
kind: Keycloak
metadata:
  ...
spec:
  externalDatabase:
    credentialsSecretRef: keycloak-db-secret

---
apiVersion: v1
kind: Secret
metadata:
    name: keycloak-db-secret
stringData:

    # updated to match https://github.com/keycloak/keycloak-containers/tree/master/server#database

    DB_VENDOR: <postgres, mysql, mariadb, oracle, mssql>
    DB_ADDR: <Database IP or URL (resolvable by K8s)>
    DB_PORT: <Database Port>   

    DB_DATABASE: <Database Name, "keycloak" as default>

    DB_SCHEMA: <Database Schema>

    DB_USER: <Database User>

    DB_PASSWORD: <Database Password>

The secret values have been adjusted to Keycloak Container. From the product perspective, we'll do a mapping step to make those settings consumable by the RHSSO image [2]. Another interesting aspect is that KeycloakBackup CR will no longer be needed as the backup should be performed by using a database Operator dedicated mechanism (probably some sort of Backup CR).

The final question is how to get a database up and running for Keycloak Operator? The answer would be to get one of the Postgresql Operators [3].

Thanks,

Sebastian

[1] https://github.com/keycloak/keycloak-documentation/blob/master/server_installation/topics/operator/external-database.adoc

[2] Scroll down to "POSTGRESQL_USER" https://github.com/jboss-container-images/redhat-sso-7-openshift-image/blob/sso74-dev/docs/templates/sso74-postgresql.adoc

[3] https://operatorhub.io/?keyword=postgre

[Craig Brookes]

Great topic thanks for outlining this in detail.

Migration from the current to the proposed implementation is something that should considered in the design doc IMO. It would be an important factor in production services that there is a seamless migration with no manual intervention.

Craig 

[Stian Thorgersen]

Isn't that what CR versions are for? 

If you use v1alpha1 it would behave as before. If you use v1alpha2 it behaves the new way.

v1alpha1 would eventually (and probably in the not too distant future since it is an alpha after all) be removed.

One v1alpha1 is removed we should also remove any capabilities within the KC operator to provision/manage/backup a db.

--
You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/80e6d896-a155-4965-9683-5c78902314bdn%40googlegroups.com.

[Stian Thorgersen]

For the name of environment variables it would make sense to align with config proposal for Keycloak.X.

--

You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/d341baa8-45dd-40f4-9e00-785fd194ab34o%40googlegroups.com.

[Sebastian Łaskawiec]

Extending Stian's comment a bit - migration is one of the hardest aspects of this proposal. We don't know what database vendor, nor database operator a user will pick. Therefore, there probably won't be any automatic migration path. 

However, I believe there should be a period of time, where we support both alpha1 (with the old db approach) and alpha2 (that includes this proposal) CRs. It shouldn't be very painful from the maintenance point of view as we'll use a completely separate set of API types and controllers. I see this as a migration mitigation option for the current product release time frame. But at some point of time, we'll just remove the alpha1 support.

[Craig Brookes]

Extending Stian's comment a bit - migration is one of the hardest aspects of this proposal. We don't know what database vendor, nor database operator a user will pick. Therefore, there probably won't be any automatic migration path.

So for existing users who are using the on cluster postgres, would this result in a secret being created that points to the existing db and release note of the postgres instance is no longer maintained by the operator and is now considered an external db?

For the name of environment variables it would make sense to align with config proposal for Keycloak.X.

This is the area that affects us more as we already have external databases. Would there be a plan to auto migrate any existing secret to any new format. Obviously if the format is not changing this is not an issue.

Craig 

 

On Tue, Jul 7, 2020 at 11:47 AM Sebastian Łaskawiec <sebastian...@gmail.com> wrote:

Extending Stian's comment a bit - migration is one of the hardest aspects of this proposal. We don't know what database vendor, nor database operator a user will pick. Therefore, there probably won't be any automatic migration path. 

However, I believe there should be a period of time, where we support both alpha1 (with the old db approach) and alpha2 (that includes this proposal) CRs. It shouldn't be very painful from the maintenance point of view as we'll use a completely separate set of API types and controllers. I see this as a migration mitigation option for the current product release time frame. But at some point of time, we'll just remove the alpha1 support.

--
You received this message because you are subscribed to a topic in the Google Groups "Keycloak Dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/keycloak-dev/uGt8wmZyOa4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to keycloak-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/CADP5VTX_YDCSAR8-9Km9TVuC5cwBjzxzuxAHvx_gRaLf1b74zw%40mail.gmail.com.

--

Craig Brookes

Integreatly 

@maleck13 Github

[Stian Thorgersen]

On Wed, 8 Jul 2020 at 12:03, Craig Brookes <cbro...@redhat.com> wrote:

Extending Stian's comment a bit - migration is one of the hardest aspects of this proposal. We don't know what database vendor, nor database operator a user will pick. Therefore, there probably won't be any automatic migration path.

So for existing users who are using the on cluster postgres, would this result in a secret being created that points to the existing db and release note of the postgres instance is no longer maintained by the operator and is now considered an external db?

For the name of environment variables it would make sense to align with config proposal for Keycloak.X.

This is the area that affects us more as we already have external databases. Would there be a plan to auto migrate any existing secret to any new format. Obviously if the format is not changing this is not an issue.

When there are API version changes would you really expect there to be an automatic upgrade? That would then somehow automatically switch your CRs from v1 to v2. I would rather expect v1 and v2 to coexist from some time allowing manual migration.

[Craig Brookes]

When there are API version changes would you really expect there to be an automatic upgrade? That would then somehow automatically switch your CRs from v1 to v2. I would rather expect v1 and v2 to coexist from some time allowing manual migration.

No. I think you are correct. I know k8s supports the idea of conversion so that you can serve multiple versions of the CR. But it should be up to the end consumer to convert to the new version (IE in our case our operator would move to using the new version and that would be rolled out as an upgrade to all clusters. I was thinking more about the secret format and whether it would be worth converting an existing secret to the new format automatically but that likely needs to be done as part of the upgrade too. Thanks for your replies

Craig 

[Kevin Fox]

I don't think this made it through before. Trying again...

While hardcoding the keys like that would make it simpler to implement on the keycloak side, it makes it a much more manual process from the user standpoint.

Ideally, the a user should be able to upload a couple of documents to Kubernetes and have the system work. One for the database, and one for Keycloak.  The Postgresql one should generate the secrets needed to contact it, and the Keycloak document should be configurable enough to pull the postgres secrets out of the k8s secrets created by whatever launched the Postgresql service (helm, an operator, etc). The mapping should be specified in the Keycloak CR. This way the user is not having to extract passwords out of a secret in one format, and uploading a second secret in a different format with the same data just so that Keycloak operator can read it. This is a really error prone workflow otherwise.

Bonus would be if it was gate tested with: https://operatorhub.io/operator/postgres-operator and https://operatorhub.io/operator/ext-postgres-operator. The former gives a simple way to building a postgres with a single doc. The latter is a nice bridge to external clusters.

Thanks,
Kevin

[Stian Thorgersen]

I find it a bit odd really to have configuration as part of a secret. I would expect DB connection to be part of the KeycloakCR with a reference to the secret and value within the secret for the password.

--

You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/d341baa8-45dd-40f4-9e00-785fd194ab34o%40googlegroups.com.

[Kevin Fox]

+1

If the config was part of the keycloak cr, and the cr pointed to the secret and optionally which key to use to read out the password, I think that would handle the use case I described in the other email.

Thanks,

Kevin

To unsubscribe from this group and stop receiving emails from it, send an email to keyclo...@googlegroups.com.

[Aymeric D.]

Hi,

+1 also

I currently use the Postgresql Operator from Zalando available here : https://operatorhub.io/operator/postgres-operator (github.com/zalando/postgres-operator)

This one allows me to create my database for Keycloak like this:

apiVersion: "acid.zalan.do/v1"

kind: postgresql

metadata:

  name: psql-keycloak

spec:

  teamId: "psql"

  volume:

    storageClass: storage-pool

    size: 8Gi

  numberOfInstances: 1

  users:

    keycloak:

      - superuser

      - createdb

  databases:

    keycloak: keycloak

  postgresql:

    version: "10"

And the Zalando operator will generate the secret and use it in a predictive secret name like this: keycloak.psql-keycloak.credentials.postgresql.acid.zalan.do

This secret contains the password and the username, so it would be good to be able to put in the CR of the Keycloak the reference and the key of the secret to be used rather than a hardcoded secret name "Keycloak-db-secret".

I understand that you will implement it, do you have a date?

If not, I can try to make a PR on my side.

I hope I used the right ML to discuss about this topic.

Thanks,

Aymeric