CDM architecture
Once you deploy the CDM, the ForgeRock Identity Platform is fully operational within
a Kubernetes cluster. forgeops artifacts provide well-tuned JVM settings,
memory, CPU limits, and other CDM configurations.
Here are some of the characteristics of the CDM:
- Multi-zone Kubernetes cluster
-
ForgeRock Identity Platform is deployed in a Kubernetes cluster.
For high availability, CDM clusters are distributed across three zones.
Go here for a diagram that shows the organization of pods in zones and node pools in a CDM cluster.
- Cluster sizes
-
When deploying the CDM, you specify one of three cluster sizes:
-
A small cluster with capacity to handle 1,000,000 test users
-
A medium cluster with capacity to handle 10,000,000 test users
-
A large cluster with capacity to handle 100,000,000 test users
-
- Third-party deployment and monitoring tools
-
-
NGINX Ingress Controller for Kubernetes ingress support.
-
Prometheus for monitoring and notifications.
-
Prometheus Alertmanager for setting and managing alerts.
-
Grafana for metrics visualization.
-
Certificate Manager for obtaining and installing security certificates.
-
Helm for deploying Helm charts for the NGINX Ingress Controller, Prometheus, and Grafana.
-
Terraform for creating example clusters.
-
- Ready-to-use ForgeRock Identity Platform components
-
-
Multiple DS instances are deployed for higher availability. Separate instances are deployed for Core Token Service (CTS) tokens and identities. The instances for identities also contain AM and IDM run-time data.
-
The AM configuration is file-based, stored at the path
/home/forgerock/openam/configinside the AM Docker container (and in the AM pods). -
Multiple AM instances are deployed for higher availability. The AM instances are configured to access the DS data stores.
-
Multiple IDM instances are deployed for higher availability. The IDM instances are configured to access the DS data stores.
-
- Highly available, distributed deployment
-
Deployment across the three zones ensures that the ingress controller and all ForgeRock Identity Platform components are highly available.
Pods that run DS are configured to use soft anti-affinity. Because of this, Kubernetes schedules DS pods to run on nodes that don’t have any other DS pods whenever possible.
The exact placement of all other CDM pods is delegated to Kubernetes.
Pods are organized across three zones in a single node pool with six nodes. Pod placement among the nodes might vary, but the DS pods should run on nodes without any other DS pods.
- Ingress controller
-
The NGINX Ingress Controller provides load balancing services for CDM deployments. Ingress controller pods run in the
nginxnamespace. Implementation varies by cloud provider.Optionally, you can deploy HAProxy Ingress as the CDM’s ingress controller instead of NGINX Ingress Controller.
- Secret generation and management
-
ForgeRock’s open source Secret Agent operator generates Kubernetes secrets for ForgeRock Identity Platform deployments. It also integrates with Google Cloud Secret Manager, AWS Secrets Manager, and Azure Key Vault, providing cloud backup and retrieval for secrets.
- Secured communication
-
The ingress controller is TLS-enabled. TLS is terminated at the ingress controller. Incoming requests and outgoing responses are encrypted.
Inbound communication to DS instances occurs over secure LDAP (LDAPS).
For more information, refer to Secure HTTP.
- Stateful sets
-
The CDM uses Kubernetes stateful sets to manage the DS pods. Stateful sets protect against data loss if Kubernetes client containers fail.
The CTS data stores are configured for affinity load balancing for optimal performance.
The AM policies, application data, and identities reside in the
idrepodirectory service. The deployment uses a singleidrepomaster that can fail over to one of two secondary directory services.
- Authentication
-
IDM is configured to use AM for authentication.
- DS replication
-
All DS instances are configured for full replication of identities and session tokens.
- Backup and restore
-
Backup and restore can be performed using several techniques. You can:
-
Use the volume snapshot capability in GKE, EKS, or AKS. The cluster that the CDM is deployed in must be configured with a volume snapshot class before you can take volume snapshots, and that persistent volume claims must use a CSI driver that supports volume snapshots.
-
Use a "last mile" backup archival solutions, such as Amazon S3, Google Cloud Storage, and Azure Cloud Storage that is specific to the cloud provider.
-
Use a Kubernetes backup and restore product, such as Velero, Kasten K10, TrilioVault, Commvault, or Portworx PX-Backup.
For more information, refer to Backup and restore overview.
-
- Initial data loading
-
When it starts up, the CDM runs the
amsterjob, which loads application data, such as OAuth 2.0 client definitions, to theidrepoDS instance.