Return the ability to import realms using a env variable in the Docker

Description

Need to return the ability to import realm at the start of the application to simplify its initial configuration

Discussion

Export/Import of realm data (JSON) #10229

Motivation

Now we have to wait until Keycloak starts and do the import using one of the ways

1. Using kcadm.sh

/opt/keycloak/bin/kcadm.sh config credentials --server http://localhost:8080/auth --realm master --user ${KEYCLOAK_ADMIN} --password ${KEYCLOAK_ADMIN_PASSWORD}
/opt/keycloak/bin/kcadm.sh create realms -f /tmp/realm.json'

1. Using new kc.sh import which requires restarting Keycloak

/opt/keycloak/bin/kc.sh import --file /tmp/realm.json

Please simplify our life and return the opportunity to make import realm from a file using a startup variable because I try to create a guide on how to simple run Keycloak in Docker Compose v2 and this problem prevents the automation of the process

Details

In the Keycloak 16.1.1 and previous versions

  keycloak:
    image: "quay.io/keycloak/keycloak:16.1.1"
    environment:
      - KEYCLOAK_IMPORT=/tmp/realm.json
    volumes:
      - ./realm.json:/tmp/realm.json:ro

In the Keycloak 17.0.0, it doesn’t work even though I tried different variables and there are no errors in the log either

  keycloak:
    image: "quay.io/keycloak/keycloak:17.0.0"
    environment:
      - KEYCLOAK_IMPORT=/tmp/realm.json
      - KC_IMPORT=/tmp/realm.json
    volumes:
      - ./realm.json:/tmp/realm.json:ro

Duplicate of #9261

[omasseau]

For me it is a must have in production mode. Be able to provide to our clients a Keycloak instance with a preconfigured realm dedicated to our application (preconfigured client, roles, token configurations, password policy, theme, …) is critical. This is also very useful te be able to quickly replicate the production environment in a staging environment at any time.

We need to automate this and cannot rely on launching scripts manually and having to wait for Keycloak to be fully started and then restarting it manually.

Sure we could develop complex scripts or solutions based on API calls, but these would involve much more work and headaches than simply being able to provide an environment variable and creating a bind mount like it was possible for the previous versions 😉

[eabykov]

@eabykov That capability is missing. The reason is that we were not sure if we should keep it as it is not something you do in production.

@pedroigor we need to automatically prepare the environment for clients to work, which means that

• clients
• users
• roles
• Tokens timings

Must be created at the deployment step. It would be very convenient to perform the initial setup without a bunch of API requests, but simply by inserting json and setting the environment variable.

PS: When we didn’t know about the possibility of importing a realm via a file and an environment variable, we still imported it only through the API

Do you agree this capability is more related to dev/testing? Would make sense to allow importing realms at startup only when in development mode?

I do not agree with you at this point, do you suggest that customers in the Prod solution create clients themselves or configure Tokens timings? I think it is necessary to automate the creation of realm not only in the dev, but also in prod

We have a set of specific applications that require pre-configured clients and roles so that the client only creates a new user and defines a role for him. PS: We also have a set of users who exist by default, they also need to be created (for example, with the requirement to confirm email or by setting a temporary password etc.)

All this is necessary so that we can raise the prod environment for users in which they will execute a command such as docker compose up -d --wait and as a result, when clicking on the url to their application, they will be able to log in with a specific user by changing the temporary password and configuring OTP, and should not execute scripts with API requests