Network authorization

Verified

Enforce access control at the L4 level using CEL expressions.

Attaches to:

Network authorization enforces access control at the L4 (transport) level, before HTTP processing. You can enforce policies for non-HTTP traffic such as raw TCP and TLS connections, and layer L4+L7 controls when you combine policies with HTTP authorization.

Network authorization uses CEL expressions evaluated against the connection’s source and destination context.

Configuration

Configure network authorization as a frontend policy under frontendPolicies.networkAuthorization.

# yaml-language-server: $schema=https://agentgateway.dev/schema/config
frontendPolicies:
  networkAuthorization:
    rules:
    - allow: 'source.address == "10.0.0.0" || source.address == "10.0.0.1"'
    - deny: 'source.address == "192.168.1.100"'
    - require: 'source.port > 1024'

gateways:
  default:
    port: 3000
routes:
- backends:
  - host: localhost:8080

Rules

Network authorization supports the same rule types as HTTP authorization:

Rule type	Behavior
`allow`	If any `allow` rule matches, the connection is permitted.
`deny`	If any `deny` rule matches, the connection is rejected.
`require`	All `require` rules must match for the connection to proceed.

Evaluation order:

If there are no rules, the connection is allowed.
If any deny rule matches, the connection is rejected.
All require rules must match.
If any allow rule matches, the connection is allowed.
If only deny rules exist, unmatched connections are allowed (denylist semantics).
If allow rules exist but none matched, the connection is rejected (allowlist semantics).

CEL context

The following CEL variables are available in network authorization rules:

Variable	Type	Description
`source.address`	`string`	IP address of the downstream connection.
`source.port`	`int`	Port of the downstream connection.
`source.tls.identity`	`string`	Client certificate identity (if mTLS).
`source.tls.subject_alt_names`	`list(string)`	Subject Alternative Names from the client certificate.
`destination.address`	`string`	IP address on agentgateway that the downstream connection was made to. This is the local address of the listener, not the address of the backend that the connection is routed to.
`destination.port`	`int`	Port on agentgateway that the downstream connection was made to.
`destination.hostname`	`string`	Server Name Indication (SNI) hostname that agentgateway read from the TLS handshake. Set only on listeners with the `TLS` protocol. Unset on HTTP and HTTPS listeners, even when the client sends SNI, and when the client sends no SNI. See the warning that follows.

Warning

destination.hostname is set only on listeners with the TLS protocol. It is unset on HTTP and HTTPS listeners, even when the client sends SNI, and for clients that send no SNI. A require rule that references an unset variable never matches, so the rule denies every such connection. Verify it against the traffic you expect before you rely on it.

Examples

Allow only private network ranges

frontendPolicies:
  networkAuthorization:
    rules:
    - allow: 'cidr("10.0.0.0/8").containsIP(source.address) || cidr("172.16.0.0/12").containsIP(source.address) || cidr("192.168.0.0/16").containsIP(source.address)'

Require mTLS client identity

frontendPolicies:
  networkAuthorization:
    rules:
    - require: 'source.tls.identity == "spiffe://cluster.local/ns/default/sa/my-service"'

Require TLS SNI

For TLS connections, use destination.hostname to require a specific SNI hostname before the connection proceeds. Because this is a require rule, a connection that carries no SNI does not match it and is rejected. Apply the policy only to listeners with the TLS protocol.

frontendPolicies:
  networkAuthorization:
    rules:
    - require: 'destination.hostname == "db.internal.example.com"'

Layered L4+L7 controls

Combine network authorization with HTTP authorization for defense in depth.

frontendPolicies:
  networkAuthorization:
    rules:
    - allow: 'cidr("10.0.0.0/8").containsIP(source.address)'

gateways:
  default:
    port: 3000
routes:
- backends:
  - host: localhost:8080
  policies:
    authorization:
      rules:
      - require: 'jwt.aud == "my-service"'

In this example, only connections from the 10.0.0.0/8 range are accepted at the network level, and those connections must also present a valid JWT with the correct audience claim.

HTTP authorization JWT authentication

Was this page helpful?