--- title: Changes description: The name of the IDM evaluation-only Docker image repository has been changed to gcr.io/forgerock-io/idm-cdk. This image repository was formerly named gcr.io/forgerock-io/idm. component: forgeops version: 7.4 page_id: forgeops::rn/archive/changes canonical_url: https://docs.pingidentity.com/forgeops/7.4/rn/archive/changes.html section_ids: june_30_2022: June 30, 2022 july_12_2021: July 12, 2021 may_12_2021: May 12, 2021 august_10_2020: August 10, 2020 february_20_2020: February 20, 2020 --- # Changes ## June 30, 2022 * IDM evaluation-only Docker image repository name change The name of the IDM evaluation-only Docker image repository has been changed to `gcr.io/forgerock-io/idm-cdk`. This image repository was formerly named `gcr.io/forgerock-io/idm`. - The IDM canonical configuration is now built into the `idm-cdk` Docker image The IDM canonical configuration for the CDK has been incorporated into the `idm-cdk` Docker image. Because of this, you no longer need to copy files from the docker/idm/config-profiles/cdk directory when you initialize a new configuration profile. Simply create a new subdirectory under the docker/idm/config-profiles directory. * New bin/ds-debug.sh script The new bin/ds-debug.sh script lets you obtain diagnostic information for any DS pod running in your cluster. It also lets you perform several cleanup and recovery operations on DS pods. For more information, refer to [Debug script](../../troubleshooting/debug-tools.html#ds-debug). - The RCS Agent has been removed from the CDM and CDK deployments The RCS Agent is no longer available in the CDM and CDK deployments. Building your own `rcs-agent` Docker image is no longer required when deploying the Ping Identity Platform on Kubernetes. * The LDIF importer is no longer used The LDIF importer is no longer used in CDM and CDK deployments. Building your own `ldif-importer` Docker image is no longer required when deploying the Ping Identity Platform on Kubernetes. - CDM deployments create a third `ds-idrepo` replica The `ds-idrepo-2` replica is now deployed as part of the CDM for failover purposes. Previously, IDM was not able to use a third `ds-idrepo` replica, so the number of `ds-idrepo` replicas was set at 2. A recent enhancement to IDM lets additional replicas be used for failover, so a third replica has been added to the CDM architecture. * Number of AM pods in small CDM clusters changed to 2 Small CDM clusters now have 2 AM pods. Previously, they had 3 AM pods. - Limitation on IDM workflow support in the CDK and CDM The Release Notes now [document the limitation](../limitations.html#idm-limitations) that the CDK and CDM are not preconfigured to support IDM's workflow engine. Note that this limitation has existed since version 7.0 of the platform, when the CDK and CDM starting using DS as the IDM repository. * Changes to the steps for configuring the CDK and CDM to use a CA certificate The forgeops install command now installs cert-manager as part of CDK and CDM deployment. Because of this, the steps for configuring the CDK and CDM to use a certificate from a CA have changed. Refer to [TLS certificate](../../how-to/security/https.html#tls-certificate) for details. - Use the new cluster/minikube/cdk-minikube utility to create a Minikube cluster The new cluster/minikube/cdk-minikube utility lets you create a Minikube cluster that's configured for running the CDK. The [Minikube cluster](../../cdk/minikube/setup/vm.html) page now includes an example of how to run this utility. * New recommendation: use the Hyperkit and Docker drivers for Minikube clusters It's now recommended that you use the Hyperkit driver for Minikube clusters on macOS systems, and the Docker driver for Minikube clusters on Linux systems. ForgeRock has tested Minikube clusters with these two drivers, and the new cluster/minikube/cdk-minikube utility creates Minikube clusters with these two drivers by default. - CDK deployments on Minikube require the volume snapshots plugin CDK deployments on Minikube now require you to enable the volume snapshots plugin. Refer to [Minikube cluster](../../cdk/minikube/setup/vm.html). ## July 12, 2021 * New amster command Use the new amster import command instead of the config.sh import command to import sample AM run-time data to the CDK. - Statement on `forgeops` repository feature evolution The new [`forgeops` repository feature evolution](../evolution.html) section has been added to these [ForgeOps 7.4 release notes](../rn.html) to clarify the meaning of feature statuses, such as technology preview, evolving, legacy, deprecated, and removed. ## May 12, 2021 * Release branch Version 7.1.0 of the `forgeops` repository is available in the `release/7.1.0` branch. Previously, release tags were used for `forgeops` repository releases. - Several Docker images from ForgeRock are supported in production deployments The Docker images that implement UI elements in the Ping Identity Platform are now supported for use in production deployments. For more information, refer to [Base Docker images](../../how-to/base-docker-images.html). Previously, users were required to build all the Docker images for the platform for use in their production deployments. * Third-Party Kubernetes support changes The section, [Third-Party Kubernetes Services](../../start/support.html#kubernetes-services) in [Support from ForgeRock](../../start/support.html) has been revised. - Secure LDAP Inbound communication to DS instances now occurs over secure LDAP (LDAPS). Previously, communication was over LDAP connections. * IDM is now a Kubernetes deployment Previously, IDM was deployed as a stateful set. - Python 3 is now on the list of required third-party software The `bin` directory in the `forgeops` repository now contains scripts written in Python 3. Python 3 has been added to the list of third-party software that you need to install before using the `forgeops` repository. Note that Homebrew users can install Python 3 using the command, `brew install python`. * Python scripts Some of the functionality available in bash scripts is replaced by the identical functionality in Python scripts. No functionality has been removed with these script changes: * clean.sh - Use the cdk delete Python script instead. * ds-operator.sh - Use the ds-operator Python script instead. * print-secrets.sh - Use the print-secrets Python script instead. * secret-agent.sh - Use the secret-agent Python script instead. - Secrets are not created automatically when you install the platform on the CDM A new step to configure the Secret Agent and create secrets is required when deploying the CDM. The new step—running the kubectl apply command—has been added to the CDM Cookbooks. Previously, this was done automatically by the skaffold run command. Note that Skaffold still automates secret creation when you deploy the CDK. * Volume snapshots technology preview Support for volume snapshots has been added to the DS operator technology preview. For more information, refer to [the DS operator README](https://github.com/forgerock/ds-operator#readme). - Configuration expressions in the AM configuration are preserved when the configuration is exported Configuration expressions used in an AM configuration profile are now preserved in that profile after you export a configuration from the CDK to a `forgeops` repository clone. For more information, refer to [About property value substitution](../../cdk/develop/value-substitution.html) in the CDK documentation. * CDK and CDM deployment verified on newer Kubernetes versions CDK and CDM deployments are now verified on newer Kubernetes versions. For more information, refer to [Validated software versions](../versions.html). - The Secret Agent operator lets you change individual administration passwords The [Secret Agent operator](../../how-to/security/secret-agent.html) now supports [changing individual administration passwords](../../how-to/security/secret-agent.html#password-changes). If periodic password changes are a requirement for your organization, you can change individual administration passwords as needed. * CDM deployments no longer create a third `ds-idrepo` replica The `ds-idrepo-2` replica is no longer deployed as part of the CDM. IDM did not use this replica, and removing the replica improved replication performance for the CDM, and lowered the cost of the deployment. - CDM backups are now taken from the `-0` DS instances by default CDM backups are now taken from the `ds-idrepo-0` and `ds-cts-0` DS instances by default. In previous versions, backups were taken from the `ds-idrepo-2` and `ds-cts-2` DS instances by default. * Regions for CDM cluster creation no longer default With this change, you must explicitly configure a region when you run one of the CDM cluster creation scripts. For details, refer to the environment setup sections for [Google Cloud](../../cdm/gke/setup/project.html), [AWS](../../cdm/eks/setup/aws-env.html), and [Azure](../../cdm/aks/setup/subscription.html). Previously, CDM clusters were created in specific regions by default. - Long form command-line options for the `ingress-controller-deploy.sh` command Long form command-line options are now available for the `ingress-controller-deploy.sh` command. To refer to the available options, run `/path/to/forgeops/bin/ingress-controller-deploy.sh --help`. * How to eliminate the need to accept a self-signed certificate on Minikube deployments The CDK documentation now includes an optional step for adding a secret to CDK deployments. The secret contains a TLS certificate issued by an external certificate authority (CA), or by a local CA that you create using the mkcert utility. Users who access ForgeRock web-based applications on deployments that have this type of secret do not need to accept a self-signed certificate. - All main AM run-time data types supported when exporting configuration data The `export` and `sync` options of the `config.sh` command let you export AM run-time data from a running CDK instance to a configuration profile stored in a local clone of the `forgeops` repository. With this release, the `export` and `sync` options can now export all of these types of run-time data: * OAuth 2.0 clients * OpenID Connect 1.0 clients * PingGateway, Web, Java, and SOAP STS agents * Policies * SAML v2.0 circles of trust and entities In previous releases, only OAuth 2.0 clients and PingGateway agents were exported. * Performance benchmark changes Two benchmarks are available for Ping Identity Platform version 7: * An [authentication rate benchmark](../../how-to/benchmark/authrate.html), which measures authentication performed with AM REST API calls to an AM server configured to use CTS-based (stateful) sessions. * An [OAuth 2.0 authorization code flow benchmark](../../how-to/benchmark/oauth2.html), which measures the throughput and response time of an AM server performing authentication, authorization, and session token management. AM is configured to use client-based (stateful) sessions for this benchmark. Contact your ForgeRock sales representative to obtain our results for benchmarks for these Ping Identity Platform version 7. - Small and medium clusters now use a single node pool For simpler deployments, small and medium CDM clusters now use a single node pool for all pods instead of using a second node pool for DS pods. Large CDM clusters continue to use two node pools. * Task maps and checklists in the documentation The CDK and CDM documentation has been improved! New checklists help you navigate through set up and deployment activities: * [CDK deployment checklist](../../cdk/overview.html) * [Minikube setup checklist](../../cdk/minikube/setup/mini-setup.html) * [CDM deployment checklist](../../cdm/overview.html) * [GKE environment setup checklist](../../cdm/gke/setup/setup-env.html) * [EKS environment setup checklist](../../cdm/eks/setup/setup-env.html) * [AKS environment setup checklist](../../cdm/aks/setup/setup-env.html) Task maps are provided with each set up and deployment activity. They help you determine where you are in the deployment process, and indicate the next step you'll perform. - Minikube `cni=true` option ForgeRock now recommends that you start Minikube with the `cni=true` option. Starting Minikube with this option circumvents [Minikube issue 1568](https://github.com/kubernetes/minikube/issues/1568), which required users to run the Minikube VM in promiscuous mode. In [Minikube cluster](../../cdk/minikube/setup/vm.html): * The step to create the Minikube VM has been modified to use the `cni=true` option. * The instruction to circumvent [Minikube issue 1568](https://github.com/kubernetes/minikube/issues/1568) by placing the Minikube VM in promiscuous mode has been removed. ## August 10, 2020 * CDM on newer Kubernetes versions CDM has been tested on newer versions of Kubernetes. Refer to [Validated software versions](../versions.html) for details. - New print-secrets.sh script Secrets for both the CDK and the CDM are generated dynamically when they start up. To obtain the secrets, run the print-secrets.sh script. For example, to obtain the `amadmin` user's password: ``` $ cd /path/to/forgeops/bin $ ./print-secrets.sh amadmin ``` * New UI pods Several new pods, deployed in both the CDK and the CDM, handle common user interface functions. The new pods are named `admin-ui`, `end-user-ui`, and `login-ui`. - No need to explicitly scale AM after CDM startup The new version of the CDM starts three pods. Previous versions of the CDM started a single AM pod. After CDM startup, you restarted the AM pod, and then ran the `kubectl scale` command to scale the number of AM pods. * Different directory superuser DN and backend database In this revision, the CDK and the CDM use: * Directory superuser's DN: `uid=admin` * Directory backend database: `appData` No longer used: * Directory superuser's DN: `cn=Directory Manager` * Directory backend database: `userRoot` - Increased virtual hardware requirements for running the CDK on Minikube CPU and memory requirements for running the CDK on Minikube have increased: * 3 CPUs (or more) are now required. * 12288 MB (or more) virtual memory are now required. * New technique for building base Docker images Because Dockerfiles for the base Docker images no longer reside in the `forgeops` repository, the steps for building base Docker images have changed. Refer to [Base Docker images](../../how-to/base-docker-images.html) for the new steps. - New technique for IDM REST API access Accessing the IDM REST API now requires an access token issued by AM. Refer to *Access the IDM REST APIs* in [IDM Services](../../cdk/access.html#idm-services) for an example. ## February 20, 2020 * Deployment with Skaffold and Kustomize instead of Helm This revision uses Skaffold and Kustomize, instead of using Helm charts, to deploy the platform. Skaffold can detect changes to the file system that holds the AM, IDM, and PingGateway configurations. When it detects a change to one of those configurations, it rebuilds the `am`, `idm`, or `ig` Docker image. Then, it reorchestrates the Ping Identity Platform deployment. Note that changes to dynamic AM configuration data—policies and application data—are not automatically detected by Skaffold. Changes to dynamic AM configuration data still need to be exported using Amster. For more information about customizing the Ping Identity Platform configuration when working with Skaffold, refer to [Docker Image Development](../../cdk/develop/intro.html). - Changes to CDM zones and node pools In the new revision, CDM deployments use three availability zones and two node pools. In previous versions, CDM deployments used two zones and a single node pool. * New scripts for installing third-party components This revision includes improved bash scripts for installing the Ingress-NGINX controller, Certificate Manager, Prometheus, Grafana, and Alertmanager in a CDM cluster. The new scripts are [ingress-controller-deploy.sh](https://github.com/ForgeRock/forgeops/blob/release/7.4-20240805/bin/ingress-controller-deploy.sh), [certmanager-deploy.sh](https://github.com/ForgeRock/forgeops/blob/release/7.4-20240805/bin/certmanager-deploy.sh), and [prometheus-deploy.sh](https://github.com/ForgeRock/forgeops/blob/release/7.4-20240805/bin/prometheus-deploy.sh). - Helm tiller pod no longer required Although the CDM still uses Helm charts to install the Ingress-NGINX controller and Prometheus, a Helm tiller pod is no longer needed in the CDM cluster. In the previous version, CDM deployment required a running tiller pod to support Helm chart deployment. * Revised benchmarking technique This revision uses Gradle to trigger AM and IDM simulations for benchmarking performance. - Revised backup technique In this revision, backup is greatly simplified. Backups are made to local disks running in the same pods in which DS runs. The previous version required an NFS-mounted external storage device (Google Filestore or EFS) to be available for backup. The external storage device is no longer needed. * Modified DS topology in the CDM This revision's DS topology: * Two DS services are used: the CTS and ID Repo services. CTS directories hold CTS tokens. ID Repo directories hold identities, configuration data, policies, application data, and IDM run-time data. * Three replicas of each service are deployed. The previous version's DS topology: * Three DS services were used: CTS, AM userstore, and AM configuration store. A PostgreSQL database hosted IDM run-time data. * Two replicas of each service were deployed. For more information, refer to [CDM architecture](../../cdm/architecture.html). - PingGateway not deployed by default In this revision, PingGateway is not deployed as part of the CDK or CDM, and benchmarks for PingGateway performance are no longer published in the *CDM Cookbooks*. You can still deploy PingGateway with the CDK or CDM; use the Kustomize base and overlays in the /path/to/forgeops/kustomize/ig directory. * CDM sizing and benchmarks The CDM Cookbooks provide the steps for creating medium-sized (10,000,000 users) clusters. You can still create small-sized (1,000,000 users) and large-sized (100,000,000) clusters using the artifacts in the `forgeops` repository. Benchmarks for small, medium, and large clusters are available for Google GKE. Benchmarks for medium clusters only are available for Amazon EKS and Microsoft Azure AKS. - Randomly generated administrator passwords The CDM and CDK use administrator passwords that are randomly generated by the secrets generator. Refer to the *UI and API Access* pages in the CDM and CDK documentation for information about how to obtain the administrator passwords. * New Docker image and pod names ForgeRock's Docker image repository names are now `am`, `idm`, and `ig`. In previous versions, the Docker image repository names were `openam`, `openidm`, and `openig`. Kubernetes pod names now include the strings `am`, `idm`, and `ig`. In previous versions, the pod names included the strings `openam`, `openidm`, and `openig`. - New method for building base Docker images As with previous versions, you must still build your own base Docker images for the Ping Identity Platform for production deployments on Kubernetes. In this version, you must download the ForgeRock binaries manually before building the Docker images. In the previous version, a script automatically downloaded the binaries from ForgeRock's Artifactory repository. This script has been removed from the `forgeops` repository. For more information, refer to [Base Docker images](../../how-to/base-docker-images.html). * AM WAR file customization script removed The customize-am.sh script is no longer available in this revision of the `forgeops` repository. To customize the AM web container in this revision, add instructions to the `am` Dockerfile to copy your customizations into the /usr/local/tomcat/webapps/am directory. - New backup-loader.sh script The new backup-loader.sh script lets you create PVCs from DS binary backups before you start the platform, so that DS instances in the platform use the data from the PVCs. * Different default URLs Use the following default URLs to access Ping Identity Platform services in this revision: * AM: https\://`namespace`.iam.`domain`/am * IDM: https\://`namespace`.iam.`domain`/idm * PingGateway: https\://`namespace`.iam.`domain`/ig - Support for newer versions of CDM third-party software The CDM includes more recent versions of these third-party components. Refer to these scripts for details about versions of third-party software currently used with the CDM: [ingress-controller-deploy.sh](https://github.com/ForgeRock/forgeops/blob/release/7.4-20240805/bin/ingress-controller-deploy.sh), [certmanager-deploy.sh](https://github.com/ForgeRock/forgeops/blob/release/7.4-20240805/bin/certmanager-deploy.sh), and [prometheus-deploy.sh](https://github.com/ForgeRock/forgeops/blob/release/7.4-20240805/bin/prometheus-deploy.sh). * Certificate Manager no longer required for the CDK on Minikube Support for self-signed certificates and signing certificates is built into the CDK when it runs on Minikube. Because of this, you no longer need to deploy Certificate Manager when deploying the CDK on Minikube. - Self-signed certificates for GKE CDM deployments CDM deployments use Certificate Manager for TLS support. In previous versions, Certificate Manager was configured to call Let's Encrypt to provide certificates for CDM deployments on GKE. In this revision, Certificate Manager is configured to provide a self-signed certificate for CDM deployments on GKE. * *DevOps Developer's Guide* replaced The *DevOps Developer's Guide* has been replaced with two new guides: * *DevOps Developer's Guide: Using Minikube* * *DevOps Developer's Guide: Using a Shared Cluster* The content in the new guides is similar to the *DevOps Developer's Guide*. Each of the new guides limits its descriptions to a single type of cluster, thus simplifying procedures. - *Before You Deploy* section moved The information formerly in the *Before You Deploy* section of the *Release Notes* has been moved. This information is now available where it's needed instead of on linked pages. * *DevOps QuickStart Guide* removed The *DevOps QuickStart Guide* tutorial has been removed from the documentation. - CDM and CDK installation requires Linux or macOS ForgeRock supports CDK and CDM installation on Linux and macOS only. If you use a Microsoft Windows computer, you'll need to create a Linux virtual machine for installing the CDK and the CDM.