This page documents limitations on the ForgeRock Identity Platform when deployed on a Kubernetes cluster in the cloud.
- 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 macOS systems running ARM-based chipsets is not supported.
Running the CDK is currently not supported on macOS systems running an ARM-based chipset, such as the Apple M1 or Apple M1 Max.
If you have a Mac with an ARM-based chipset, you can:
- The bin/config.sh 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.sh 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 and save it to your configuration profile, 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.sh 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.
- 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.
- AM must be reconfigured and restarted if the number of DS pods changes.
In DS 7.1, 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
ctspods in a running AM deployment.
- Single realm deployments are recommended.
ForgeRock recommends using a single root realm with no subrealms when deploying AM on Kubernetes.
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.1. Note that AM authentication trees are not stateful, and do not have this limitation.
- 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.
- The IDM repository is deployed in a single master topology.
The IDM repository is deployed as a single DS master. Failover to a secondary DS replica is available. Multimaster replication is not currently supported for the IDM repository.
- 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.