KEYCLOAK-12449: Fix internal keycloak URL.

[mgoltzsche]

JIRA ID

KEYCLOAK-12449

Additional Information

The operator failed to sync CRs into its keycloak cluster using the
service since it used http and the service's IP on keycloak's SSL port.
This is a blocker - especially in non-openshift clusters without Route
CRD support.
This PR makes the operator use https and the service's name instead.

Verification Steps

see https://issues.redhat.com/browse/KEYCLOAK-12449

Checklist:

• Verified by team member
• Comments where necessary
• Automated Tests
• Documentation changes if necessary - not necessary

[coveralls]

Coverage increased (+0.02%) to 41.982% when pulling 7594aa9 on mgoltzsche:master into 69f79ad on keycloak:master.

[mgoltzsche]

Now I've also added a test to increase coverage.

[apigeeks-lee]

having same problem.
please release ASAP or post a work-around as this is a blocking issue.

[slaskawi]

Thanks for the fix @mgoltzsche !

The fix looks great, but I don't like the tests. We put a lot of effort to avoid mocking at any type (this decision is aligned with all other Keycloak projects). Could you please extend one of our integration tests (this one for example) to check if the InternalURL is created correctly?

[mgoltzsche]

@slaskawi I removed my old test and added the InternalURL check to the integration test where you suggested.

[kfox1111]

I'm seeing the same issue.

[slaskawi]

Thanks for the Pull Request @mgoltzsche !

@stianst @abstractj This one is ready to be integrated.

[kfox1111]

There a plan for when 8.0.2 would be released with the fix?

[slaskawi]

@kfox1111 It depends on the other sub-projects. We release all Keycloak bits together. However, you can use the master tag of the image, which is rebuilt on every commit.

[kfox1111]

Ah, nice. I'll give that a try. Thanks!

[kfox1111]

Question in general. How do you override the tag to master when your using the olm? It kept reverting things so I scaled down the olm to 0 so I could edit it for testing. But that seems like a wrong thing to do.

Master does seem to have the patch. Which is good. Some things wrong:

• it deploys a keycloak 7.0.1 rather then 8.0.1 for some reason.
• the other custom objects like keycloakuser still doesnt work. tls issue:

user:
  status:
    message: 'error performing token request: Post https://keycloak.my-keycloak-operator.svc:8443/auth/realms/master/protocol/openid-connect/token:
      remote error: tls: handshake failure'
    phase: failing

I also can't curl from minikube to the cluster ip:
$ curl https://10.109.53.109:8443
curl: (35) error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure

Guessing this is a cert issue?
Is there any integration with cert-manager planned?
I looked at the keycloak crd and don't see a way to pass a cert.

[mgoltzsche]

@kfox1111 Keycloak is configured to use the TLS secret sso-x509-https-secret within the CR's namespace. The secret name is hardcoded here. You could let cert-manager manage it.

Any client you want to connect to Keycloak needs to know its CA certificate (ca.crt within the secret).

[kfox1111]

No workie:

Steps to reproduce:
* Installed cert-manager, olm, and then the keycloak operator.
* provisioned a local ca and cert for keycloak with certmanager.
* scaled down olm to 0 so it wouldn't interfere with following steps.
* edited the keycloak operator deployment to point to the master tag
* uploaded the keycloak cr. Keycloak starts up with 7.0.1 for some reason. Master seems broken. It doesnt' work though.
* scaled down the keycloak operator
* edited the keycloak statefulset updating the image to 8.0.1. It also fails to come up.

Logs from keycloak:

Added 'admin' to '/opt/jboss/keycloak/standalone/configuration/keycloak-add-user.json', restart server to load user
-b 0.0.0.0
=========================================================================

  Using PostgreSQL database

=========================================================================

18:04:57,698 INFO  [org.jboss.modules] (CLI command executor) JBoss Modules version 1.9.1.Final
18:05:00,036 INFO  [org.jboss.msc] (CLI command executor) JBoss MSC version 1.4.11.Final
18:05:00,209 INFO  [org.jboss.threads] (CLI command executor) JBoss Threads version 2.3.3.Final
18:05:02,314 INFO  [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: Keycloak 8.0.1 (WildFly Core 10.0.3.Final) starting
18:05:03,693 INFO  [org.jboss.vfs] (MSC service thread 1-2) VFS000002: Failed to clean existing content for temp file provider of type temp. Enable DEBUG level log to find what caused this
18:05:15,696 INFO  [org.wildfly.security] (ServerService Thread Pool -- 20) ELY00001: WildFly Elytron version 1.10.4.Final
18:05:24,935 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
18:05:26,452 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
18:05:27,680 INFO  [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: Keycloak cumulative patch ID is: base, one-off patches include: none
18:05:27,993 WARN  [org.jboss.as.domain.management.security] (MSC service thread 1-1) WFLYDM0111: Keystore /opt/jboss/keycloak/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
18:05:29,614 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
18:05:29,628 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: Keycloak 8.0.1 (WildFly Core 10.0.3.Final) started in 31723ms - Started 55 of 78 services (32 services are lazy, passive or on-demand)
The batch executed successfully
18:05:32,243 INFO  [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: Keycloak 8.0.1 (WildFly Core 10.0.3.Final) stopped in 275ms
18:05:56,777 INFO  [org.jboss.modules] (CLI command executor) JBoss Modules version 1.9.1.Final
18:05:57,870 INFO  [org.jboss.msc] (CLI command executor) JBoss MSC version 1.4.11.Final
18:05:57,907 INFO  [org.jboss.threads] (CLI command executor) JBoss Threads version 2.3.3.Final
18:05:59,880 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: Keycloak 8.0.1 (WildFly Core 10.0.3.Final) starting
18:06:01,500 INFO  [org.jboss.vfs] (MSC service thread 1-2) VFS000002: Failed to clean existing content for temp file provider of type temp. Enable DEBUG level log to find what caused this

Then the pod is restarted and keeps doing the same thing. It never comes up.
I see the secret volume referenced in the keycloak-0 pod yaml.
The file does exist too:
$ kubectl get secrets -n my-keycloak-operator sso-x509-https-secret
NAME TYPE DATA AGE
sso-x509-https-secret kubernetes.io/tls 3 41m

[kfox1111]

Looks like the liveness hook was killing it prematurely. I temporarily removed and keycloak came up.

I can not test though that the operator based objects now work with this patch in place. As if I leave the operator running so it processes KeycloakUser objects, it forces in the liveness hook back in, and that kills the keycloak prematurely.

[slaskawi]

@kfox1111 Yes, this is a known issue: https://issues.redhat.com/browse/KEYCLOAK-12398

Unfortunately there's no workaround for it at the moment.