Skip to main content

Ingress Configuration - Details

← Back to Ingress Configuration Tutorial

This document provides comprehensive information about ingress configuration, gateway selection, and advanced networking options.

How Ingress Works

The Platform Application Operator automatically:

  1. Selects a gateway
    1. Using your explicit assignment in spec.networking.ingress.gateway
    2. Or by using the Environment's default from the cluster-data ConfigMap in the platform-operator namespace
  2. Creates routing rules to forward traffic to your service
  3. Configures the hostname based on the application name and cluster domain
  4. Sets up TLS/HTTPS termination at the gateway

What Gets Created

In addition to the resources from Basic Deployment, the platform creates:

  • HTTPRoute (or VirtualService if using Istio gateway): Routes external traffic to your service
  • Gateway configuration: Configures the ingress gateway
  • DNS entries (if configured): Automatic DNS registration for your hostname
  • TLS certificates: Automatically provisioned and managed

Advanced Configuration

Custom Hostnames

Override the default hostname pattern:

networking:
ingress:
enabled: true
hostnames:
- my-custom-domain.com
- another-domain.example.com

Since this requires Certificates to be configured as well, check out our specific guide here (Coming Soon).

Path-Based Routing

Route only specific paths to your application:

networking:
ingress:
enabled: true
path: /api # Only route /api/* to this service

Gateway Selection

The platform provides a standard set of preconfigured gateways. You can either:

  • Explicitly specify a gateway in your PlatformApplication spec
  • Use the Environment default (recommended for most applications)

Available Gateway Options

The platform deploys four gateways organized along two dimensions:

  • Visibility: Where the application can be accessed from
    • public: Accessible from the public internet
    • internal: Accessible only within the enterprise network (VPN or private network)
  • Authentication: Whether OAuth2 authentication is required
    • open: No authentication required (anyone with network access can reach the application)
    • oidc: Requires OAuth2 authentication via identity provider

This creates a 2x2 matrix of gateway options:

GatewayVisibilityAuthenticationUse Case
public-openPublic InternetNonePublic-facing applications, marketing sites, public APIs
public-oidcPublic InternetOAuth2 requiredSaaS applications, authenticated portals, customer-facing apps
internal-openEnterprise NetworkNoneInternal tools, monitoring dashboards, development environments
internal-oidcEnterprise NetworkOAuth2 requiredInternal applications with sensitive data, admin panels

Explicit Gateway Assignment

To specify a gateway:

networking:
ingress:
enabled: true
gateway: public-open # Use specific gateway configuration

Environment Default Gateway

If you don't specify a gateway (spec.networking.ingress.gateway), the platform uses the Environment's default gateway.

Each Environment is configured with a default gateway stored in the cluster-data ConfigMap in the platform-operator namespace.

Viewing the Environment's default gateway:

# View the entire cluster-data ConfigMap
kubectl get configmap cluster-data -n platform-operator -o yaml

# Extract just the default gateway
kubectl get configmap cluster-data -n platform-operator -o jsonpath='{.data.defaultGateway}'
  • You can find the Environment specification in your .platform repository (organization/environments.yaml) to see what the default gateway is set to as well.
  • This is not available through ArgoCD, since the 'platform-operator' namespace is managed by the platform.

When to Explicitly Specify a Gateway

Most applications should rely on the Environment default. Explicitly specify a gateway when:

  • Your application needs different access patterns than the environment default
  • You're building a public marketing site in a production environment that typically requires authentication
  • You need to expose an internal tool publicly for a specific use case