ForgeOps

CDK Architecture: Shared Cloud Cluster

This documentation describes the legacy CDK implementation, which will be deprecated in an upcoming release. We strongly recommend that you transition to the current CDK implementation as soon as possible.

A shared cluster lets multiple developers deploy and configure the ForgeRock Identity Platform on a single cloud-based Kubernetes cluster. A Kubernetes administrator sets up the shared cluster, then provides details to the developers so that they can access the cluster. Each developer then works in their own isolated environment within the cluster, called a namespace.

The CDK uses Skaffold to trigger Docker image builds and Kubernetes orchestration. Here’s what Skaffold does:

  1. Calls the Docker client on the local computer to build and tag their customized Docker images for the ForgeRock Identity Platform. The customized images are based on Docker images in ForgeRock’s public Docker registry, gcr.io/forgerock-io.

  2. Pushes the Docker images to a Docker registry accessible to the shared cluster.

  3. Calls Kustomize to orchestrate the ForgeRock Identity Platform in your namespace. Kustomize uses the Docker images that Skaffold pushed to your Docker registry.

The following diagram illustrates how the CDK uses Skaffold to build Docker images locally, push them to a shared registry, and orchestrate them in a shared cluster:

Diagram of a development environment that uses a shared cluster.

After deploying the ForgeRock Identity Platform, you’ll see the following pods running in your namespace:

Diagram of the deployed CDK.
am

The am pod runs AM.

When AM starts, it obtains its configuration from the /home/forgerock/openam/config directory [1].

After the am pod has started, an Amster job is triggered. This job populates AM’s run-time data.

ds-cts-0

The ds-cts-0 pod runs the directory service used by the AM Core Token Service.

ds-idrepo-0

The ds-idrepo-0 pod runs the following directory services:

  • Identity repository shared by AM and IDM

  • IDM repository

  • AM application and policy store

idm

The idm pod runs IDM.

When IDM starts, it obtains its configuration from the /opt/openidm/conf directory [2].

In containerized deployments, IDM must retrieve its configuration from the file system and not from the IDM repository. The default values for the openidm.fileinstall.enabled and openidm.config.repo.enabled properties in the CDK’s system.properties file ensure that IDM retrieves its configuration from the file system. Do not override the default values for these properties.

UI pods

Several pods provide access to ForgeRock common user interfaces:

  • admin-ui

  • end-user-ui

  • login-ui

In addition to these pods, you’ll see that two jobs that load data into the environment have run to completion:

  • The amster job, which loads application data, such as OAuth 2.0 client definitions, to the idrepo DS instance.

  • The ldif-importer job, which sets passwords for the DS idrepo and cts instances.

The CDK also requires three other services that are external to your namespace. These services must be installed by your cluster administrator before you attempt to install the CDK in your shared cluster:

  • An NGINX ingress controller, for providing external access to services in the shared cluster.

  • Certificate manager, for obtaining and installing security certificates.

  • ForgeRock’s Secret Agent operator, for generating and managing Kubernetes secrets.

Next Step

1. When you build the am Docker image, the AM configuration files are copied from the /path/to/forgeops/docker/7.0/am/config directory to the /home/forgerock/openam/config directory.
2. When you build the idm Docker image, the IDM configuration files are copied from the /path/to/forgeops/docker/7.0/idm/conf directory to the /opt/openidm/conf directory.
Copyright © 2010-2024 ForgeRock, all rights reserved.