IP Whitelisting for Managed Clusters

Managed clusters can be configured to restrict Kubernetes API server access to a set of authorized IP ranges (CIDR blocks). This ensures that only known networks — such as corporate VPNs, offices, data centers, and platform control plane infrastructure — can reach the cluster API server.

There are two configuration points depending on the cluster type:

1. Environment-level — for managed AKS/EKS clusters (PlatformCluster resources)
2. Organization-level — for virtual clusters on orchestration infrastructure (vClusters)

---

Managed Clusters (AKS/EKS)

For managed clusters provisioned through Environment resources, add authorized IP ranges under the security.networking section of the Environment spec.

Configuration

apiVersion: meta.p6m.dev/v1alpha1
kind: Environment
metadata:
  name: my-environment
spec:
  security:
    networking:
      apiServerAuthorizedIpRanges:
        # Platform control plane IPs (always include these — get current values from your platform team)
        - "192.0.2.10/32"
        - "192.0.2.11/32"
        - "192.0.2.12/32"
        # Platform orchestration IPs (always include these — get current values from your platform team)
        - "198.51.100.10/32"
        - "198.51.100.11/32"
        - "198.51.100.12/32"
        # Tenant-specific egress IPs
        - "203.0.113.0/24"    # Corporate VPN
        - "198.51.100.0/24"   # Office network

How It Works

1. The platform organization operator reads spec.security.networking.apiServerAuthorizedIpRanges from the Environment resource
2. The operator populates these ranges into the corresponding PlatformCluster resource under kubernetes.apiServer.authorizedIpRanges
3. Crossplane compositions apply the IP restrictions to the cloud provider (AKS authorized IP ranges, EKS public access CIDRs, etc.)

What to Include

Category	Description
Platform Control Plane	Ybor control plane egress IPs — required for platform management
Platform Orchestration	Ybor orchestration cluster egress IPs — required for ArgoCD and CI/CD
Orchestration Clusters	Any additional orchestration clusters (e.g., Azure-based) that manage the environment
Tenant Egress	Corporate VPNs, offices, warehouses, data centers — any network that needs kubectl access
CI/CD Runners	GitHub Actions runner IPs or other CI/CD infrastructure that deploys to the cluster

warning

Omitting required IPs will immediately block access from those networks. Always include the platform control plane and orchestration IPs, and verify CI/CD pipeline connectivity before applying to production.

---

Virtual Clusters (vClusters on Orchestration)

Virtual clusters running on orchestration infrastructure use a different configuration path through the Organization resource.

Configuration

apiVersion: meta.p6m.dev/v1alpha1
kind: Organization
metadata:
  name: my-org
spec:
  controlPlane:
    security:
      restrictAccess: true
      additionalAllowedSourceRanges:
        # Tenant-specific egress IPs
        - "203.0.113.0/24"    # Corporate VPN
        - "198.51.100.0/24"   # Office network

How It Works

When restrictAccess is set to true, the operator computes the full set of allowed IP ranges by merging two sources:

1. DEFAULT_ALLOWED_IPS environment variable — configured on the operator deployment, contains the platform control plane and orchestration IPs. These are automatically included so you don't need to repeat them in the Organization spec.
2. additionalAllowedSourceRanges — tenant-specific IPs defined on the Organization resource (VPNs, offices, data centers, etc.)

The merged list is applied to the vCluster's API server access configuration.

tip

The Organization-level config applies to all virtual clusters under that organization. You only need to set this once per organization, not per environment.

Fields

Field	Type	Description
restrictAccess	boolean	When true, enables IP whitelisting on vClusters. When false or unset, no restrictions are applied.
additionalAllowedSourceRanges	string[]	List of CIDR blocks for tenant-specific networks. Platform IPs are added automatically via DEFAULT_ALLOWED_IPS.

---

Rollout Procedure

Recommended Order

1. Dev — Apply to development environments first
2. Stg — After Dev validation, apply to staging
3. Prd — After Stg validation, apply to production during a maintenance window

Pre-Rollout Checklist

• Collect all tenant egress IPs (VPNs, offices, warehouses, data centers)
• Confirm platform control plane and orchestration IPs are included
• Verify CI/CD pipeline egress IPs are accounted for
• Confirm DEFAULT_ALLOWED_IPS is configured on the operator deployment (for vClusters)
• Test on a non-production cluster first

Verification

After applying the configuration:

# Check the PlatformCluster resource has the expected IP ranges
kubectl get platformcluster <name> -o jsonpath='{.spec.kubernetes.apiServer.authorizedIpRanges}'

# Verify API server is accessible from a whitelisted IP
kubectl cluster-info

# Verify API server rejects connections from a non-whitelisted IP
# (test from an IP not in the whitelist — should timeout or be refused)

Rollback

To remove IP restrictions, delete the apiServerAuthorizedIpRanges field from the Environment spec (for managed clusters) or set restrictAccess: false on the Organization spec (for vClusters). The operator will reconcile and remove the restrictions.