You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently, Keycloak in UDS Core only supports connecting to external database instances using username/password. When deploying to AWS, other apps in UDS Core support connecting to external resources using IAM/IRSA. While username/password is functional, alternative approaches that do not require static credentials should be favored.
A popular approach is to use the AWS JDBC Driver, as per the AWS Docs. However, there are some known limitations to this solution, namely the limitation of 200 connections per second. This limitation could potentially be avoided by using connection pooling or RDS Proxy, as noted under recommendations in the AWS Docs.
There are examples of other open source projects successfully adopting the AWS JDBC driver in their Keycloak installations, such as Camunda. We would need to consider how to package the driver .jar files and any dependencies in our Keycloak package (perhaps an airgap-friendly approach is to include it in the uds-identity-config image).
Describe the solution you'd like
Given UDS Core is deployed with Keycloak configured for HA in AWS
When Keycloak authenticates to RDS
Then AWS IAM is used as opposed to static credentials
Describe alternatives you've considered
Using EKS Pod Identity may simplify the configuration required. There are some examples available online around using this method for authenticating to external PostgreSQL Databases from EKS (ref, ref). I am uncertain if this has been tested with Keycloak.
Additional context
N/A
The text was updated successfully, but these errors were encountered:
It may also be worth seeing if the JDBC driver is something the Ironbank and Chainguard maintainers would be willing to add by default to their images. I believe we've had success with Chainguard in the past requesting addition of plugins (Sonarqube comes to mind). This might not be worth pursuing though since the upstream would likely not add it - just wanted to float it as a possibility.
Changing the JDBC driver for AWS use cases seems like a good idea. The only thing we might want to consider is the performance. Do we have any requirements in this regards (e.g. the minimum throughput or latency)?
As a potential future implementation detail, we could leverage the Oracle JDBC Driver installation manual from Keycloak (see here) and deliver the jar as part of the keycloak-identity-config - exactly the same way as we do with custom jars and themes.
Is your feature request related to a problem? Please describe.
Currently, Keycloak in UDS Core only supports connecting to external database instances using username/password. When deploying to AWS, other apps in UDS Core support connecting to external resources using IAM/IRSA. While username/password is functional, alternative approaches that do not require static credentials should be favored.
A popular approach is to use the AWS JDBC Driver, as per the AWS Docs. However, there are some known limitations to this solution, namely the limitation of 200 connections per second. This limitation could potentially be avoided by using connection pooling or RDS Proxy, as noted under recommendations in the AWS Docs.
There are examples of other open source projects successfully adopting the AWS JDBC driver in their Keycloak installations, such as Camunda. We would need to consider how to package the driver
.jar
files and any dependencies in our Keycloak package (perhaps an airgap-friendly approach is to include it in theuds-identity-config
image).Describe the solution you'd like
Describe alternatives you've considered
Using EKS Pod Identity may simplify the configuration required. There are some examples available online around using this method for authenticating to external PostgreSQL Databases from EKS (ref, ref). I am uncertain if this has been tested with Keycloak.
Additional context
N/A
The text was updated successfully, but these errors were encountered: