Limitations
This page documents limitations on the ForgeRock Identity Platform when deployed on a Kubernetes cluster in the cloud.
On all ForgeRock Identity Platform components
- Docker images are not available for use in production deployments.
-
Except for several images that implement user interface elements, Docker images for use in production deployments of the ForgeRock Identity Platform are not available. Unsupported, evaluation-only images are available in ForgeRock’s public Docker registry. These images can be used for evaluation purposes only.
Before deploying the ForgeRock Identity Platform in production, you must build Docker images. For more information about building images for the platform, see Base Docker images.
- Running the CDK on Minikube on macOS systems with ARM-based chipsets is available on an experimental basis only.
-
Running the CDK on Minikube on macOS systems with ARM-based chipsets, such as the Apple M1 or M2, is currently available on an experimental basis only.
Refer to this ForgeRock Community article for details.
You could also:
-
Install an IDE that supports remote development. Examples include:
-
Create a Linux virtual machine in the cloud.
-
Configure the IDE to support remote development.
-
- The bin/config export command does not handle object deletion correctly.
-
Deletion of configuration objects, such as AM authentication trees and service definitions, is not handled correctly by the bin/config export command. If you have deleted one or more objects from your ForgeRock Identity Platform configuration in the CDK, and then you export the configuration from the CDK, the deleted objects will be still present in your configuration profile.
To work around this problem, locate the deleted objects in your configuration profile after you’ve run the bin/config export command. Then, delete the objects that should have been deleted from the JSON configuration files. After deleting the objects, if you build a new Docker image based on your configuration profile, the image will not contain the deleted objects.
On DS
- DS live data and logs should reside on fast disks.
-
DS data requires high performance, low latency disks. Use external volumes on solid-state drives (SSDs) for directory data when running in production. Do not use network file systems such as NFS.
- Adding DS pods to a cluster should be done in advance of anticipated additional load.
-
When you increase the number of DS pods in a cluster, they’re automatically provisioned with the same directory data in existing pods. You must allow time for the data provisioning to complete and new pods to become available.
- Database encryption is not supported.
-
The
ds-emptyDocker image—the image deployed by the DS operator—does not support database encryption. DS fails to start if it detects that any data was encrypted during the Docker build process. - DS starts successfully even when it cannot decrypt a backend.
-
When the DS master key is not available, DS starts up successfully even though is unable to decrypt a backend.
- Root file system write access is required to run the DS Docker image.
-
The DS Docker image will not run without root file system write access.
On AM
- AM must be reconfigured and restarted if the number of DS pods changes.
-
In DS 7.3, you can elastically scale the number of DS pods in Kubernetes. However, the AM configuration does not automatically respond to changes in the number of DS pods.
Because of this, you must modify the AM configuration after you scale the number of
idrepoorctspods in a running AM deployment. - Using subrealms in CDM and CDK deployments requires additional considerations.
-
If you decide to deploy AM with subrealms, you’ll need to configure the subrealms in the DS repository before starting AM. For more information, see the comments in the DS Dockerfile.
- Session stickiness is recommended for all deployments.
-
ForgeRock recommends that you configure your load balancer to use sticky sessions to achieve better performance.
- Session stickiness is required for some deployments.
-
Two AM features are stateful, and require you to configure your load balancer to use sticky sessions:
-
SAML v2.0 single logout.
-
Browser-based authentication using authentication chains, which is deprecated in AM 7.3. Note that AM authentication trees are not stateful, and do not have this limitation.
-
- Property value substitution in is not supported for all configuration properties.
-
AM does not support property value substitution for several types of configuration properties. Refer to Property value substitution in the AM documentation for more information.
- The SOAP binding is not supported for SAML v2.0 single logout.
-
When deploying SAML v2.0 single logout, use the HTTP-POST or HTTP-Redirect bindings. The SOAP binding is not supported when AM runs in a container.
- The shared identity repository is not preconfigured for UMA deployments.
-
The shared identity repository deployed with the CDK and the CDM is not preconfigured to store UMA objects, such as resources, labels, audit messages, and pending requests.
In order to use UMA in the CDK or the CDM, you’ll need to customize your deployment. For more information, see the User-Managed Access (UMA) 2.0 Guide.
On IDM
- The IDM repository is deployed in a single master topology.
-
IDM can actively use only a single instance of DS as its repository. Should the DS instance fail, IDM can fail over to another DS instance; the limitation that only a single instance can be active applies. Using multiple DS replicas at the same time is not supported.
- The CDM and CDK are not preconfigured to support IDM’s workflow engine.
-
The CDK and the CDM use DS as the IDM repository. Because of this, the CDK and the CDM do not support IDM’s workflow engine, and workflow features are disabled.
Adding workflow support to the CDK and the CDM requires substantial, complex configuration changes, including:
-
Adding a JDBC repository to the CDK or CDM deployment.
-
Enabling workflow features in IDM.
-