Gatekeeper

The Gatekeeper provides security enforcement for machine-to-machine communications. Gatekeepers operate in two distinct modes configured at deployment time via Helm values or YAML configuration. Separate Gatekeeper instances must be deployed for each mode.

Technical Artifact Names

The Gatekeeper's Helm chart (corsha/proxy), Docker image (corsha-docker.jfrog.io/proxy), and related technical artifacts use "proxy" in their names for backward compatibility, even though the product is now called the Gatekeeper.

---

Choosing Between Firewall and Proxy Modes

The operational mode you choose depends on your security requirements, network architecture, and performance constraints:

Factor	Firewall Mode	Proxy Mode
OSI Layer	Layer 2 (connection control) with deep-packet inspection	Layer 7 (application)
Latency Impact	Microseconds	Milliseconds
Protocol Support	All protocols (TCP, UDP, industrial, proprietary)	HTTP/HTTPS, OPC UA TCP, Modbus TCP
Machine Discovery	Passive network observation	Manual configuration or identity provider integration
Authentication Model	Connection-based access control	MFA credential validation or existing credential mapping
Deployment Location	Network boundaries, inline with traffic	In front of APIs or integrated into API gateways
Primary Use Case	Protocol-agnostic network segmentation and connection control	API authentication and identity-based access control
Legacy System Support	Excellent (no modification required)	Limited to TCP-based protocols
Zero-Trust Model	Connection blocking/allowing	Request authentication

Decision Guidelines:

• Choose Firewall Mode when you need protocol-agnostic security, microsecond latency, passive discovery, or need to control non-HTTP protocols
• Choose Proxy Mode when you need API authentication for HTTP/HTTPS traffic or supported industrial protocols (OPC UA, Modbus TCP)

Many organizations deploy both modes: Firewall Mode for all network traffic control, Proxy Mode for HTTP APIs and supported industrial protocols.

---

Firewall Mode: Connection-Based Access Control

Overview

In firewall mode, the Gatekeeper operates at layer 2 for connection control while performing deep-packet inspection to identify protocols and analyze application-layer traffic. This provides protocol-agnostic security for all machine-to-machine communications with microsecond-level latency.

How It Works

Passive Discovery: Gatekeepers observe network traffic and passively discover machines without requiring agents, configuration changes, or instrumentation. As machines communicate, Gatekeepers identify them and build an inventory of active machines.

Connection Rule Enforcement: Gatekeepers evaluate connections against connection rules synchronized from the Corsha mIDP. Rules define how machines can communicate. Gatekeepers enforce rules locally — blocking or allowing traffic based on the configured enforcement mode.

Continuous Rule Synchronization: Gatekeepers continually sync connection rules from the Corsha mIDP. Rule updates propagate to all Gatekeepers automatically, enabling dynamic policy updates without redeployment.

Progressive Security Hardening

Firewall mode supports three enforcement modes that enable gradual rollout: Observe-Only, Allow by Default, and Block by Default. This progressive approach allows you to validate policies before enforcement.

See Deployment Lifecycle for detailed guidance on enforcement mode progression, metrics to track, and decision criteria for transitioning between phases.

Performance Characteristics

• Latency Impact: Microseconds (layer 2 operation)
• Protocol Support: All protocols—IP, TCP, UDP, industrial, proprietary
• Deep Protocol Inspection: EtherNet/IP, OPC UA, Modbus TCP, BACnet/IP
• Throughput: Wire-speed forwarding with minimal overhead

When to Use Firewall Mode

• All Protocol Types: Securing non-HTTP protocols (industrial, proprietary, custom protocols)
• Microsecond Latency Requirements: Real-time systems where millisecond delays are unacceptable
• Passive Discovery: When machines cannot be modified or instrumented
• Protocol-Agnostic Security: Mixed environments with diverse protocols requiring unified control
• Zero-Trust Network Segmentation: Micro-segmentation without deploying agents
• Connection-Based Control: Controlling which machines can communicate regardless of application protocols

Deployment

---

Proxy Mode: API Authentication and Identity Management

Overview

In proxy mode, the Gatekeeper operates at layer 7 to provide authentication and identity management for API traffic. The Gatekeeper supports two operational modes: Authenticator-based MFA and Adaptive IAM.

Operational Modes

Authenticator-Based MFA: Authenticators deployed with API clients inject dynamic, one-time MFA credentials into requests. The Gatekeeper validates these credentials before forwarding traffic to protected services. Credentials are embedded in the X-Corsha-Cred header for HTTP traffic, or injected directly into protocol handshakes for industrial protocols like OPC UA and Modbus TCP.

Adaptive IAM: The Gatekeeper identifies and authenticates traffic based on existing credentials already present in API requests—no Authenticators required. Supported credential types include JWT bearer tokens, basic authentication, custom headers, and API keys. The Gatekeeper maps these credentials to machine identities and enforces policies based on group membership and attributes.

How It Works

Credential Processing: In Authenticator-based mode, Gatekeepers extract MFA credentials from the X-Corsha-Cred header or protocol-specific messages. In Adaptive IAM mode, Gatekeepers inspect requests for existing credential patterns (Authorization headers, API keys, custom headers).

Identity Validation: The Gatekeeper validates credentials against the Corsha DLN (for MFA credentials) or maps existing credentials to machine identities in the mIDP (for Adaptive IAM).

Request Forwarding: Only authenticated requests are forwarded to protected services. Invalid or missing credentials result in HTTP 401 Unauthorized responses.

Performance Characteristics

• Latency Impact: Milliseconds (connection handling and credential validation)
• Protocol Support: HTTP/HTTPS, OPC UA TCP, Modbus TCP
• Integration: Standalone or embedded in API gateways

When to Use Proxy Mode

Authenticator-Based MFA:

• HTTP/HTTPS API protection with dynamic MFA credentials
• Industrial TCP protocols (OPC UA, Modbus TCP) requiring authentication
• Continuous authentication for API traffic
• Adding MFA to APIs without native authentication

Adaptive IAM:

• HTTP/HTTPS APIs using existing credentials (JWT, basic auth, API keys)
• API traffic visibility without deploying Authenticators
• API gateway integration with identity-based policies
• Leveraging existing authentication for machine identity

Deployment

Proxy mode Gatekeepers can be deployed in Kubernetes environments or integrated into existing API gateways.

API Gateway Integration: See integration guides:

• Kong Gateway
• F5

See Proxy Mode Deployment Guide for detailed instructions.

---

Best Practices

Firewall Mode

1. Start with Observe-Only: Deploy in Observe-Only mode for 2-4 weeks to discover all machines and connection patterns before enforcing policies.

2. Organize with Groups: Create machine groups based on function and security zone before creating connection rules.

3. Progressive Hardening: Transition through enforcement modes: Observe-Only → Allow by Default → Block by Default.

4. Use Connection Canvas: Visualize connections before creating blocking rules to avoid unintended traffic disruption.

5. Deploy at Boundaries: Place Gatekeepers at network boundaries or inline with traffic flows for maximum visibility.

6. Monitor Continuously: Watch logs and Connection Canvas after enforcement mode changes to catch unintended blocks.

7. Use Protocol Rules Sparingly: Protocol enforcement rules override connection rules. Use them for broad policies (e.g., block all web traffic) rather than specific machine-to-machine restrictions.

8. Avoid Rule Conflicts: Do not create opposing protocol enforcement rules for the same port/protocol combination. The system does not prevent conflicting configurations, and the resulting behavior is undefined.

9. Toggle Instead of Delete: Protocol enforcement rules can be toggled to inactive state rather than deleted, preserving rule definitions for future use.

10. Test Protocol Rules Carefully: Before creating protocol enforcement rules in production, verify they won't interfere with required connections, as they override all connection rules.

Proxy Mode

1. Deploy Close to Services: Place Gatekeepers as close as possible to protected API services to minimize latency.

2. Disable Direct Access: Configure network policies to prevent clients from bypassing the Gatekeeper and accessing services directly.

3. Use Gateway Integration: For existing API gateway deployments, use Corsha's gateway plugins rather than standalone Gatekeepers.

4. Monitor Failed Auth: Enable logging of failed authentication attempts to detect compromised clients or misconfigured Authenticators.