Skip to main content

Private Cloud overview

Pangea Private Cloud allows organizations to run the complete Pangea platform within their own infrastructure boundary (supporting AWS, Azure, and GCP). Unlike Edge deployment where configuration and monitoring happen through Pangea's cloud, Private Cloud hosts both the control plane and data processing components entirely in your cloud environment.

If an organization needs to maintain complete control over their security infrastructure while leveraging advanced security services, Pangea Private Cloud will enable them to run Pangea's security services directly within their cloud infrastructure.

Why deploy Pangea Private Cloud?​

  • Data Sovereignty: Keep sensitive data within your infrastructure boundaries and specific geographic regions.
  • Compliance: Meet strict regulatory requirements for data handling and processing.
  • Performance: Minimize latency by running services closer to your applications.
  • Control: Maintain complete oversight of your security services infrastructure.
  • Integration: Seamlessly connect with your existing security and monitoring tools.

Understanding Pangea Private Cloud deployments​

Since Pangea Private Cloud will be deployed and managed through your environment, you will need to understand the basic components of Pangea's Private Cloud before moving on to the installation guides.

The following sections will guide you through the prerequisites for setting up your environment and will help you build an understanding of the underlying components in Pangea's Private Cloud.

Prerequisites​

  • Provide your Pangea representative with your AWS Account ID so Pangea can grant your team access to the required ECR account and S3 bucket
  • A running Amazon EKS (Elastic Kubernetes Service) cluster
  • kubectl configured to communicate with your EKS cluster
  • Helm 3.x, aws cli, jq, yq installed on the machine which you plan to use for the installation

Set Up AWS S3 Policies​

Your Kubernetes pods need access to the pangea-artifacts S3 bucket (e.g., pangea-artifacts-us-west-1, pangea-artifacts-us-east-1, or pangea-artifacts-eu-central-1, depending on your region) to retrieve updates, configurations, and resource files required by Pangea services.

Pangea supports a few different methods for setting up this policy. You can follow either of these processes to apply the policy:

  • Option 1: Attach permissions to your Kubernetes Service Accounts using IAM Roles for Service Accounts (IRSA) See a tutorial here.

  • Option 2: Attach this policy to your node group role using the AWS IAM Management Console You can learn how to edit node IAM policies here.

Pangea S3 IAM Policy​
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "artifactsBucketList",
      "Effect": "Allow",
      "Action": ["s3:ListBucketVersions", "s3:ListBucket"],
      "Resource": "arn:aws:s3:::pangea-artifacts-us-west-1"
    },
    {
      "Sid": "artifactsBucketRead",
      "Effect": "Allow",
      "Action": [
        "s3:GetObjectVersionAttributes",
        "s3:GetObjectVersion",
        "s3:GetObjectAttributes",
        "s3:GetObject"
      ],
      "Resource": "arn:aws:s3:::pangea-artifacts-us-west-1/*"
    }
  ]
}

Architecture overview​

Pangea Private Cloud is deployed using Helm, which installs:

  • A Kubernetes operator (controller)
  • Required RBAC configurations
  • Custom Resource Definitions (CRDs)

The operator manages the lifecycle of Pangea services, handling operations such as:

  • Initial bootstrapping
  • Service upgrades
  • Service additions/removals
  • Configuration management
  • Database migrations

Installation components​

Custom Resource Definitions (CRDs)​

When you deploy Pangea Private Cloud, you'll need a way to tell Kubernetes how to manage Pangea-specific resources, like service configurations and cluster settings. This is where Custom Resource Definitions (CRDs) come in - they extend Kubernetes to understand and manage Pangea components as if they were built-in Kubernetes resources.

Pangea uses two main CRDs:

  • PangeaCluster: Defines your entire Pangea deployment, including which services to enable.
  • ServiceConfig: Manages individual service settings and API tokens.

Think of these like blueprints - the PangeaCluster CRD is the blueprint for your entire Pangea deployment, while ServiceConfig CRDs are blueprints for configuring individual services (like embargo, file-intel, or redact) within that deployment.

PangeaCluster CRD​

This CRD defines the PangeaCluster Resource type. This includes authentication to the cluster and the services enabled within it. The Controller will manage bootstrapping the cluster which includes making migrations, deployments, services, and creating any necessary cronjobs.

This custom resource is Cluster scoped, and all the actual workloads will be created in the same namespace as the controller. Note that you will also need to create secrets for database credentials, and those should also be in the same namespace as the controller.

A PangeaCluster definition to enable Embargo and File Intel service is shown below:

Example PangeaCluster CRD

apiVersion: cluster.pangea.cloud/v1beta1
kind: PangeaCluster
metadata:
  name: pangea-cluster
spec:
  # The version of Pangea Private Cloud to deploy
  version: 0.7.5

  common:
    image:
      # ECR registry containing Pangea service images
      registry: 227262099132.dkr.ecr.us-east-1.amazonaws.com
      # Should match the version specified above
      tag: 0.7.5

    # Database configuration for storing service data
    database:
      host: "postgres.pangea-private-beta1.svc.cluster.local"
      port: 5432
      name: msf
      auth:
        # References to Kubernetes secrets containing database credentials
        usernameSecretRef:
          name: pangeadbuser.postgres.credentials.postgresql.acid.zalan.do
          key: username
        passwordSecretRef:
          name: pangeadbuser.postgres.credentials.postgresql.acid.zalan.do
          key: password

  services:
    # Core services - always enabled and required (authn and gateway)
    authn:
      image:
        repository: private_cloud_authn
    gateway:
      image:
        repository: private_cloud_gateway

    # Optional services - can be enabled as needed
    embargo:
      enabled: true
      image:
        repository: private_cloud_embargo
    intelligence:
      enabled: true
      image:
        repository: private_cloud_intelligence
      virtualServices:
        file-intel:
          enabled: true
note

Important Information about PangeaCluster:

  • All workloads are created in the same namespace as the controller.
  • Database credential secrets must be in the controller's namespace.
  • AuthN (Authentication) and Gateway services are mandatory core components.
  • Additional services can be enabled/disabled as needed.
  • The version and image tag should always match.
  • The registry URL will be provided by Pangea during onboarding.
ServiceConfig CRD​

This CRD represents a single configuration for a single service. By creating this custom resource, the Controller will save that configuration into the database, and create an API token with appropriate access for use by application code.

This custom resource is Namespace scoped, and needs a reference to the PangeaCluster. The API token will be saved into a secret in the same namespace this custom resource is created in.

warning

ServiceConfigs most likely will be deprecated in future, once Pangea User Console is supported in private cloud.

Embargo service configuration

# Embargo Service Configuration Example
apiVersion: cluster.pangea.cloud/v1beta1
kind: ServiceConfig
metadata:
  name: embargo-config
  namespace: pangea-private-beta1
spec:
  # References the PangeaCluster name defined above
  cluster: pangea-cluster
  serviceName: "embargo"
  # Service-specific configuration in JSON format
  data: { "enabled_default_lists": ["US - ITAR"] }

File Intel service configuration

# File Intel Service Configuration Example
apiVersion: cluster.pangea.cloud/v1beta1
kind: ServiceConfig
metadata:
  name: fileintel-config
  namespace: pangea-private-beta1
spec:
  cluster: pangea-cluster
  serviceName: "intelligence"
  data: { "reputation_default_provider": "crowdstrike" }
note

Important Information about ServiceConfig:

  • Each service requires its own ServiceConfig resource.
  • The controller automatically creates an API token for each service configuration.
  • API tokens are stored as Kubernetes secrets in the same namespace as the ServiceConfig.
  • The cluster field must reference a valid PangeaCluster name.
  • The data field structure varies by service type.
  • This resource type will be deprecated once the Pangea User Console supports private cloud deployments.

Next steps​

Now that you understand what Pangea Private Cloud offers and what you'll need, you're ready to begin installation. Choose your operating system to get started:

Was this article helpful?

Contact us