Release notes archive

Updates for ForgeRock Identity Platform version 7.5 are available in the release/7.4-20231003 branch of the forgeops repository.

New evaluation-only Docker image versions are now available for the following ForgeRock Identity Platform components:

For more information about changes to the ForgeRock Identity Platform, refer to the Release Notes for platform components at https://backstage.forgerock.com/docs.

The evaluation-only Docker images for ForgeRock Identity Platform version 7.5 are multi-architecture images that support both the ARM and x86 architectures.

To upgrade to the new versions, you’ll need to rebuild your custom Docker images. Refer to Base Docker images for instructions.

The new multi-architecture images let you run the platform natively on ARM and x86 CPUs without using an emulation layer. Because of this, the limitation against running the CDK on Minikube on macOS systems with ARM-based chipsets, such as the Apple M1 or M2, has been removed.

ForgeRock’s evaluation-only Docker images are all based on Java 17. All the Dockerfiles for building base Docker images specify Java 17.

In version 7.3, some of ForgeRock’s evaluation-only Docker images were based on Java 11.

The techniques for backing up and restoring CDM data have changed. Refer to updates on the following pages:

Refer to the backup and restore overview for more information.

The DS operator is deprecated in version 7.4 of the ForgeRock Identity Platform. Because of this:

If you take volume snapshots for backups, you must continue to deploy the deprecated DS operator together with the CDK and the CDM.

The DS operator became available with version 7.2 of the ForgeRock Identity Platform. If you deployed the CDK or the CDM with version 7.2 or 7.3 of the platform:

The ForgeOps artifacts for deploying ForgeRock Identity Platform 7.3 are deprecated. You should migrate to version 7.4 as soon as you’re able to.

The ds-backup.sh script does not support scheduling backups that use the export-ldif utility. It only supports scheduling CDM data backups that use the dsbackup utility.

Use Terraform to create clusters in which you can install the CDM. Terraform artifacts are now available in the top-level terraform directory of the new forgeops-extras repository. Install Terraform software before you install the CDM to take advantage of this new capability.

The cluster-up.sh and cluster-down.sh scripts are no longer available. Use Terraform for cluster creation and deletion instead.

You’ll find changes on the following pages in the documentation:

Deployment environments let you manage deployment manifests and image defaulters for multiple environments in a single forgeops repository clone.

Specify a deployment environment by using the forgeops command’s new --deploy-env option.

By default, the image defaulter and generated Kustomize manifests reside in the kustomize/deploy directory.

Each deployment environment has its own image defaulter, located in the kustomize/deploy-environment/image-defaulter directory.

When you specify a deployment environment, Kustomize manifests are generated in the kustomize/deploy-environment directory. For example, if you ran forgeops generate --deploy-env production, Kustomize manifests would be placed in the kustomize/deploy-production directory.

You can now install HAProxy Ingress as the ingress controller for CDM deployments.

NGINX Ingress Controller remains the default ingress for controller for CDK and CDM deployments.

A reference for the forgeops command is now available here.

When you create a cluster for deploying version 7.3 of the platform, use Kubernetes version 1.25.

The cdk-minikube script has been modified to use the stable Kubernetes version instead of version 1.23.3. Refer to the Minikube start command reference for details about which Kubernetes version is currently considered to be the stable version.

When you deploy the NGINX Ingress Controller in your CDM cluster, use version 1.4.0^[1] or higher.

Three additional limitations on DS in CDK and CDM deployments are now documented here:

Please note that these are not new limitations. They had inadvertently been omitted from the DS limitations section in the documentation.

Large CDM deployments are now configured to run in a single node pool.

The CDM architecture previously used two node pools: one for the DS pods, and another for all the other pods in the CDM deployment.

The config export am and config export idm commands now have added functionality to create new configuration profiles.

You are no longer required to create and populate subdirectories under the /path/to/forgeops/docker/am/config-profiles and /path/to/forgeops/docker/idm/config-profiles directories the first time you export configuration from the CDK to a new configuration profile in your forgeops repository clone.

The tf-apply script creates a kubeconfig file when it creates a cluster. The documentation has been modified to support changing the Kubernetes context using KUBECONFIG environment variables instead of assuming you use the default kubeconfig file, $HOME/.kube/config.

You can now use any namespace you want for CDM deployment.

Previously, cluster creation scripts created the prod namespace, and some scripts defaulted to using this namespace for CDM deployment.

The forgeops build command now uses Docker rather than Skaffold to build and push Docker images.

Because of this, you no longer need to install Skaffold software when deploying the CDM or the CDK.

The forgeops build command’s --push-to option replaces the --default-repo option.

When running the forgeops build command on Minikube, you must now specify --push-to none with the forgeops build command to push a Docker image to the Docker registry embedded in the Minikube cluster. Previously, it was not necessary to specify the --default-repo option when running the forgeops build command on Minikube.

The forgeops delete command now issues multiple confirmation prompts, letting you choose to delete all PVCs, volume snapshots, and/or secrets from a CDK or CDM deployment.

Previously, you could only choose to delete all three deployment artifacts, or none of them.

The forgeops delete command’s new --force --yes option lets you suppress all confirmation prompts.

The tf-apply command uses Terraform rather than eksctl to create EKS clusters.

Because of this, you no longer need to install eksctl software when deploying the CDM.

The name of the AM evaluation-only Docker image repository has been changed to gcr.io/forgerock-io/am-cdk. This image repository was formerly named gcr.io/forgerock-io/am-base.

The AM canonical configuration for the CDK has been incorporated into the am-cdk Docker image.

Because of this, you no longer need to copy files from the docker/am/config-profiles/cdk directory when you initialize a new configuration profile. Simply create a new subdirectory under the docker/am/config-profiles directory.

The ForgeOps artifacts for deploying ForgeRock Identity Platform 7.2 are deprecated. You should migrate to version 7.3 as soon as you’re able to.

The cluster-up and cluster-down scripts are no longer available. Use Terraform for cluster creation and deletion instead.

The forgeops build command’s --default-repo option is no longer available. It’s been replaced by the new --push-to option.

The cicd directory has been removed from the forgeops repository.

A new step to back up the Kubernetes secrets that contain the DS master and TLS keys has been added to the instructions for deploying the CDM.

It is extremely important to back up these secrets and retain them in a secure location. Loss of these secrets could result in the inability to restore data from backups.

The Secret Agent operator page previously stated that the Secret Agent operator generates all secrets required for a ForgeRock Identity Platform deployment.

This page has been corrected to state that the Secret Agent operator generates all secrets required for a ForgeRock Identity Platform deployment except for the DS master and TLS keys. In version 7.5, the DS operator calls the certificate manager to generate these two keys.

The recommendation that you always configure cloud secret management has been relaxed. ForgeRock now recommends that you configure cloud secret management only when you have multiple deployments that need to use the same secrets.

The Base Docker images page has been significantly updated. A new section, Create Docker images for use in production, explains how to build customized Docker images for the ForgeRock Identity Platform that: