--- title: "Prerequisites" description: "Required infrastructure and access before installing the Guardian Platform." source: "Guardian Platform" --- ## Overview This document outlines the prerequisites and foundational requirements for deploying the Guardian Platform. This entails both installing the application workloads to a Kubernetes cluster and configuring the required cloud resources. This guide provides administrators with an overview of the deployment lifecycle, hardware and software prerequisites, and the required infrastructure components. ## Deployment architecture To successfully install the platform, specific infrastructure components must be prepared. The installation is driven from a deployment host that applies configurations to the target Kubernetes cluster. It is recommended to prepare a dedicated machine to act as the deployment host. This host must have network access to the Kubernetes cluster and the ability to download the deployment Helm package. For troubleshooting purposes, it is recommended that the host also has access to the provisioned cloud resources and the deployed platform components (for example, the ability to query REST APIs using `curl` or `wget`). The Guardian Platform is deployed using Helm charts. The deployment mechanism connects to the target cluster and applies the Helm configurations. While the guide provides sufficient information, executing this process requires foundational knowledge of `kubectl` and `helm`. The target environment is a Kubernetes cluster (such as Amazon EKS, Microsoft Azure AKS, or Google Cloud GKE) where the Guardian Platform microservices operate. To ensure data persistence, security, and compliance, the platform integrates with external object storage, key management, and a relational database. Application data is stored in a PostgreSQL database, which can be deployed internally within the Kubernetes cluster or provisioned as an external managed service. User authentication and access management are delegated to an OIDC/OAuth 2.0 Identity Provider (IdP), which can be an internal service (Keycloak) or an external enterprise provider. ## System requirements A successful deployment requires administrators to provision specific resources and ensure appropriate access permissions are configured. This section details the resources that must be provided before initiating the deployment process. ### Recommended requirements for the deployment host The deployment host serves as the control point for the installation. It is recommended to manage the configuration files required for installation (such as Helm values) through a version control system like `git`. Cloning a Git repository containing these configurations directly to the deployment host ensures versioning and traceability. The recommended specifications for the deployment host are detailed below. #### Operating system Red Hat Enterprise Linux (RHEL) 10 is the preferred operating system. RHEL 9 is also supported and suitable if permitted by organizational policies. #### Command line tools Specific administrative tools must be installed on the deployment host: - `helm` 3.20 or later and `kubectl` to manage the Kubernetes deployments. - `git` to clone the deployment repository. - `telnet`, `curl`, or `wget` for installation validation. - A command-line text editor, such as `vi` or `nano`, for editing configuration files. #### Deployment repository The [deployment repository](https://github.com/eqtylab/deployment) holds the bootstrap charts, helper scripts, example values, and `guardctl` that the deployment guides use. Clone it on the deployment host at the tag for the platform version you are deploying, such as `platform/v1.2.1`: ```bash git clone --branch platform/v https://github.com/eqtylab/deployment.git ``` #### Network access While the platform can be installed in air-gapped environments, standard deployments require network connectivity to several endpoints: - The designated image registry to pull or download the deployment charts and platform Docker images. - The target Kubernetes cluster API to execute `helm` and `kubectl` commands. - A secrets management service, such as AWS Secrets Manager, for retrieving credentials. This is optional but highly recommended. Ensure that appropriate registry credentials are provided to allow the Kubernetes cluster to download the platform container images. For verified Cloudsmith deliveries, obtain a prod entitlement token from EQTY Lab, prepare separate Helm and Kubernetes registry credentials, and confirm that `cloudsmith-delivery.json` exists for the selected stable version. Until that marker exists, use the existing GHCR credentials and installation instructions. See [Connected Install](./connected-install.mdx). #### SSL certificates If the organization utilizes a Private Certificate Authority (CA) to secure internal resources, the necessary trusted root SSL certificates must be pre-installed on the host system. This ensures that tools like `curl`, `helm`, and `kubectl` can establish secure HTTPS connections to registries, APIs, and cloud services without certificate validation errors. ## Cloud infrastructure requirements Guardian delegates state (data) management, cryptography, and authentication to cloud infrastructure. Administrators must ensure these resources are provisioned prior to initiating the platform deployment. At a high level, the following infrastructure must be provisioned and accessible from the Kubernetes cluster: - **Kubernetes Cluster:** A supported managed Kubernetes environment, version 1.29 or later with `linux/amd64` nodes, is required to host the platform workloads. The release manifest records the minimum version and architecture for each release. - **Ingress and DNS:** A valid DNS record must point to a configured NGINX Ingress Controller connected to the cluster. This endpoint must be secured with valid TLS certificate(s); see [Domain and TLS](./domain-and-tls.mdx). - **Relational Database:** A PostgreSQL instance is required for application data persistence. This can be deployed as an internal in-cluster service or as an external managed service. - **Key Management Service:** A cryptographic service with permissions to create keys and sign payloads must be available to the platform. - **Object Storage:** A storage bucket is required for storing Guardian Platform artifacts. - **Identity Provider (IdP):** An OIDC/OAuth 2.0 provider must be configured with authorized callback and logout URLs. Authentication services can be provided by an external customer-provisioned service, such as Microsoft Entra ID, or by an internal provider (Keycloak). - **Backup Instruments:** Enterprise backup and disaster recovery mechanisms must be available to ensure data durability. This typically involves native cloud backup tools, such as AWS Backup, Google Cloud Backup and DR, or Azure Backup, to safeguard the external database and object storage components. The following table outlines the required infrastructure components across different cloud providers: | Component | Service: AWS | Service: Google Cloud | Service: Azure | | :--------------------- | :-------------------------------------- | :------------------------------------- | :------------------------------------------ | | Kubernetes Cluster | Amazon EKS | Google Kubernetes Engine (GKE) | Azure Kubernetes Service (AKS) | | Object Storage | Amazon S3 | Cloud Storage | Azure Blob Storage | | Key Management Service | AWS KMS | Cloud KMS | Azure Key Vault | | Database | Amazon RDS for PostgreSQL (or internal) | Cloud SQL for PostgreSQL (or internal) | Azure Database for PostgreSQL (or internal) | ### Cluster capacity The chart's default replica counts and resource settings give a starting point for sizing the cluster. Only Auth Service and the bundled PostgreSQL set resources by default; the other values are the suggestions commented in the chart's `values.yaml`. | Component | Replicas | Requests (CPU / memory) | Limits (CPU / memory) | | :------------------- | :------- | :---------------------- | :-------------------- | | Auth Service | 2 | 100m / 128Mi | 500m / 512Mi | | Governance Service | 2 | 250m / 256Mi | 500m / 512Mi | | Integrity Service | 2 | 100m / 256Mi | 500m / 512Mi | | PDFGen | 2 | 100m / 256Mi | 500m / 512Mi | | Guardian | 1 | 50m / 128Mi | 200m / 256Mi | | PostgreSQL (bundled) | 1 | 500m / 1Gi | 2 / 2Gi | Together these request about 1.7 CPU and 3 GiB of memory, with limits of about 6.2 CPU and 6.3 GiB. The bundled PostgreSQL also claims a 10 GiB persistent volume. The optional Gateway Stack sets no resources by default; add capacity for it when enabled. ## Conclusion Deploying the Guardian Platform is not a one-shot action. Rather, it is a multi-stage process that consists of the following lifecycle phases: 1. Provisioning the Kubernetes cluster. 2. Provisioning the required cloud resources. 3. Granting access permissions from the cluster to the cloud resources. 4. Configuring the Guardian Platform. 5. Executing the deployment. 6. Installation qualification. In enterprise environments, deploying the Guardian Platform typically requires collaboration across multiple functional teams. Generally, the deployment process involves a cloud infrastructure team to provision external resources (such as object storage, key management systems, and databases), an identity and access management (IAM) or security team to configure identity providers and grant access permissions, and a platform administration team to configure and execute the Helm deployment and manage the Kubernetes workloads. ## Related - [Deployment Process](./deployment-process.mdx) — the steps that follow once these resources exist - [Air-Gapped Install](./airgap-install.mdx) — what a restricted environment needs beyond these resources - [External Database](./external-database.mdx) — choosing between the bundled and a managed PostgreSQL - [Authentication](./authentication.mdx) — choosing and configuring the identity provider - [Object Storage](./object-storage.mdx) — provider guides for attachment and integrity storage - [Key Management](./key-management.mdx) — provider guides for signing keys