Kubernetes Networking

Gateway API Rate Limit Rule

#Application Protection

Plugin: nevisadmin-plugin-nevisproxy

Defines a rate limiting rule for the Gateway API.

Max Requests

Configure the maximum number of requests allowed in the selected time period.

Time Period

Configure the time period over which the rate limit is applied (for example, per second, per minute, or per hour).

Gateway API Settings

#Application Protection #Kubernetes #Add-ons

Plugin: nevisadmin-plugin-nevisproxy

In Kubernetes deployments, a Gateway API controller terminates TLS connections and forwards requests to nevisProxy. Basic settings are available in the Gateway API tab in the Virtual Host pattern.

This pattern provides additional options, e.g. related to TLS secrets and client certificate authentication. Assign the pattern to your Virtual Host using Additional Settings.

TLS Secrets

Configure custom TLS certificate(s) for your domain(s).

Enter the fully qualified domain name (FQDN) in the key column and the name of the Kubernetes Secret in the value column.

The domain names correspond to the Frontend Addresses of your Virtual Host which use the HTTPS protocol.

The referenced Kubernetes Secret must:

Be of type kubernetes.io/tls
Contain the following entries in data:
- tls.key – the private key (PEM encoded)
- tls.crt – the certificate (PEM encoded, including the full certificate chain is recommended)

If multiple domains use the same certificate, you can reference the same Secret for each domain.

Gateway Class Name

Defines the gatewayClassName of the generated NevisGateway resource.

Gateway Resource Name

Configure to use an existing Gateway resource.

If not configured, the resource will be created by the Nevis Operator.

Gateway Resource Namespace

Configure to use an existing Gateway resource.

If not configured, the resource will be created by the Nevis Operator.

If set to a different namespace than the deployment, then the IP Detection, Client Cert Auth and Key Exchange Algorithms settings require Envoy Gateway ≥ 1.8 and the label usedBy: operator.nevis-security.ch on the target gateway.

Key Exchange Algorithms

Configure the allowed key exchange algorithms for TLS connections.

By default, the default of the gateway applies.

Currently, the post-quantum hybrid X25519MLKEM768 and the legacy X25519 and P-256 algorithms are supported.

This setting requires Envoy Gateway ≥ 1.8 if Gateway Resource Namespace is set to a different namespace than the deployment.

Request Timeout

Sets spec.backendRequestTimeout on the generated NevisGateway resource, which controls how long the Gateway API controller (Envoy) waits for a response from nevisProxy (Envoy's "backend" in this context). Envoy's default is 15 seconds.

This is not the same as Request Timeout on the TCP Settings pattern: when TCP Settings is assigned to a Service (backend application), it controls the connection from nevisProxy to that backend application - a different hop than this setting.

There is a third, related timeout: nevisProxy's own Server element has a Timeout attribute (navajo.xml), defaulting to 30 seconds, which bounds how long nevisProxy itself will wait before failing a request. Raise it by assigning TCP Settings to the Virtual Host instead (via Additional Settings) and setting Request Timeout there - in that context, Request Timeout sets this instance-wide Server Timeout rather than a per-backend connection timeout.

All three timeouts can apply to the same end-to-end request, just for different hops (Envoy → nevisProxy → backend application, with nevisProxy's own Server Timeout bounding nevisProxy's overall request handling in between). The request is terminated after whichever value is lower. If you raise this setting above 30 seconds, also raise the Server Timeout accordingly. If you leave it unset, nevisProxy keeps its own default of 30 seconds, and the request will still be cut off inside nevisProxy before this higher setting is ever reached. Make sure all values are consistent with your intent.

HTTP Route Filters

A YAML list of Gateway API HTTPRouteFilter objects to apply to all rules of the generated HTTPRoute.

Filters are appended after any operator-generated filters (e.g. the host header rewrite filter).

Example — add a custom request header:

- type: RequestHeaderModifier
  requestHeaderModifier:
    add:

      - name: X-Forwarded-Proto
        value: https

At most 15 filters may be configured.

Labels

Add custom labels for the resources generated for the Gateway API integration.

The labels are applied to every Kubernetes object that the Nevis operator generates for the Gateway API (Gateway, HTTPRoute, backend Service, Backend, BackendTLSPolicy, CA ConfigMap, SecurityPolicy, ClientTrafficPolicy and BackendTrafficPolicy).

The Gateway is only labeled if the operator generates it itself. If you set Gateway Resource Name to integrate with an existing Gateway, that Gateway belongs to the platform layer, the operator never writes it, and the labels configured here have no effect on it. The other objects are labeled in both cases.

Unlike annotations, custom labels take precedence over the operator's default labels (app.kubernetes.io/* and generatedBy) on key collision.

There is one exception. The deploymentTarget and operatorServiceSelector labels on the backend Service are always set by the operator and cannot be overridden, because the Service uses them to select its pods.

Values may contain ${var.<name>} expressions to reference inventory variables.

Annotations

Add custom annotations for the resources generated for the Gateway API integration.

The annotations are applied to every Kubernetes object that the Nevis operator generates for the Gateway API (Gateway, HTTPRoute, backend Service, Backend, BackendTLSPolicy, CA ConfigMap, SecurityPolicy, ClientTrafficPolicy and BackendTrafficPolicy).

The Gateway is only annotated if the operator generates it itself. If you set Gateway Resource Name to integrate with an existing Gateway, that Gateway belongs to the platform layer, the operator never writes it, and the annotations configured here have no effect on it. The other objects are annotated in both cases.

Unlike labels, the operator's own annotations take precedence over custom annotations on key collision, and the custom value is dropped. This applies in particular to:

nevis-security.ch/last-applied-hash

There is one exception. If you set a cert-manager issuer annotation, it takes precedence and the shared cluster issuer configured in the operator is not applied. The following keys are recognized:

cert-manager.io/issuer cert-manager.io/cluster-issuer certmanager.k8s.io/issuer certmanager.k8s.io/cluster-issuer

The operator never sets issuer-kind and issuer-group, so set them alongside the issuer annotation as required by cert-manager. This only applies if the operator generates the Gateway itself, as described above.

Values may contain ${var.<name>} expressions to reference inventory variables.

Client IP Detection

Choose how to determine the source IP of the request.

The source IP is used by Envoy for the following optional features:

IP Restriction
Rate Limiting

Choose between:

disabled: use the source IP of the incoming TCP request. This option is appropriate when there are no proxies in front of the cluster.
trusted CIDRs:
- IPs found in X-Forwarded-For that match these CIDR expressions will be ignored.
- This option is recommended when you know the outbound IPs of proxies in front of the cluster.
- You have to configure Trusted CIDR Ranges to use this option.
trusted hops:
- You have to configure Trusted Hops to use this option.
- Use the n-th IP address from the X-Forwarded-For header, counting from the rightmost side.

This setting requires Envoy Gateway ≥ 1.8 if Gateway Resource Namespace is set to a different namespace than the deployment.

Trusted Hops

NumTrustedHops specifies how many trusted hops to count from the rightmost side of the X-Forwarded-For (XFF) header when determining the original client’s IP address.

If this value is set to N, the client IP is taken from the Nth address from the right end of the XFF header.

Trusted CIDR Ranges

List of CIDR ranges to trust when evaluating the remote IP address to determine the original client’s IP address.

When the remote IP address matches a trusted CIDR and the x-forwarded-for header was sent, each entry in the x-forwarded-for header is evaluated from right to left and the first public non-trusted address is used as the original client address.

If all addresses in x-forwarded-for are within the trusted list, the first (leftmost) entry is used.

Action Type

Action defines whether to allow or deny the specified IP ranges.

CIDR Ranges

List of CIDR ranges to which the Action Type applies.

Rate Limiting Rules

Assign rules to define rate limits based on the source.

Client Cert Authentication

Enables client certificate validation.

If you want to validate a client cert used by the user agent, and the TLS connection is terminated in front of the Gateway API controller, then you cannot use this setting.

Choose between:

required: Request a client cert that must be signed by a CA cert that is included in the CA Secret.

Failed verification will result in a TLS handshake error.

optional: Do optional client cert validation against the CAs.
- When no client cert is provided, the request is allowed to pass through.
- When a client cert is provided, the logic is the same as for required.
disabled (default): Do not request client certificates and do not verify them.

This setting requires Envoy Gateway ≥ 1.8 if Gateway Resource Namespace is set to a different namespace than the deployment.

CA Secret

Enter the name of the Kubernetes secret which contains the CA certificate in the key ca.crt.

If the secret does not exist, it will result in 403 (Forbidden), and with a missing ca.crt key the feature will not be enabled.

Can be created with: kubectl create secret generic ca-secret --from-file=ca.crt=ca.crt

The ca.crt file can contain multiple certificates.

CA Secret Namespace

Enter the namespace of the CA Secret.

Path Match Type

Specifies how to match the HTTP request path.

Value	Description
`PathPrefix`	Matches requests whose path starts with the configured prefix. Default.
`Exact`	Matches requests whose path is exactly equal to the configured value.
`RegularExpression`	Matches requests whose path matches the configured regular expression. Implementation-specific support.

See HTTPPathMatch for details.

Path Value

The HTTP path to match against. Defaults to /.

For Exact and PathPrefix types the value must start with / and must not contain consecutive slashes or path traversal sequences.

Example: /nevis/

NGINX Ingress Settings

#Application Protection #Kubernetes #Add-ons

Plugin: nevisadmin-plugin-nevisproxy

In Kubernetes deployments, an NGINX Ingress Controller terminates TLS connections and forwards requests to nevisProxy. Basic settings are available in the Ingress tab of Virtual Host patterns.

This pattern provides additional options, e.g. related to TLS secrets and client certificate authentication. Assign the pattern to your Virtual Host using Additional Settings.

Annotations

Add Kubernetes annotations to customize the behavior of the NGINX ingress.

Restrict access based on source IP:

nginx.ingress.kubernetes.io/whitelist-source-range: 213.189.148.0/24,173.245.48.0/20,103.21.244.0/22

Increase the maximum allowed request size:

nginx.ingress.kubernetes.io/proxy-body-size: 10m

Please read Annotations - NGINX Ingress Controller for details.

TLS Secrets

Use your own Kubernetes secrets to provide the frontend key store for a Virtual Host.

Syntax is a map of (primary) frontend address of the host to secret name.

www.siven.ch: customsecretname

Secrets must be of type: kubernetes.io/tls. Secrets must be prepared before deployment. They must contain a private key (tls.key), a matching certificate (tls.crt) and should contain the CA chain (ca.crt).

If not set the Nevis operator request certificates from the cluster issuer and generates a secret for each Virtual Host to store the required key material.

Ingress Class Name

Defines the ingressClassName of the generated ingress. It can be used instead of the kubernetes.io/ingress.class annotation to select which ingress controller should handle the generated ingress. For more information see Multiple Ingress controllers.

Client Cert Authentication

Enables client certificate validation in the NGINX Ingress.

Please note that client cert validation cannot be used when the TLS connection is terminated in front of the NGINX Ingress.

Choose between:

enabled: Request a client certificate that must be signed by a certificate that is included in the CA Secret.

Failed certificate verification will result in a status code 400 (Bad Request) (unless Error Page is configured`).

optional: Do optional client certificate validation against the CAs.

Requests will fail with status code 400 (Bad Request) when a certificate is provided that is not signed by the CA (unless Error Page is configured`). When no or an otherwise invalid certificate is provided, the request does not fail, but instead the request is allowed to pass through.

optional_no_ca: Do optional client certificate validation, but do not fail the request when the client certificate

is not signed by the CAs from CA Secret. The secret still has to exist with a valid certificate.

disabled (default): Do not request client certificates and do not verify them.

This setting is used to generate the following annotation for the NGINX Ingress:

nginx.ingress.kubernetes.io/auth-tls-verify-client

CA Secret

Enter the name of the Kubernetes secret which contains the CA certificate in the key ca.crt. If the secret does not exist it will result in 403 (Forbidden), and with a missing ca.crt key the feature will not be enabled.

Can be created with: kubectl create secret generic ca-secret --from-file=ca.crt=ca.crt

The ca.crt file can contain multiple certificates.

CA Secret Namespace

Enter the namespace of the CA Secret.

Client Cert Validation Depth

The maximum validation depth between the provided client certificate and the CA chain. (default: 1).

You only need to increase this if you only have a parent CA in the CA Secret but want to accept client certificates which have been issued by a child CA.

Error Page

An error page which will be presented in case of certificate validation error.

If you enter a path (e.g. /errorpages/403.html) then that path will be fetched from nevisProxy.

If you enter a URL then the caller is redirected to that URL.

Propagate Client Cert

Indicates if the received certificates should be passed on to nevisProxy in the header ssl-client-cert.

Path

Define a custom path for the generated ingress resource.

Example:

/nevis/

This is an ingress specific setting, the endpoints have to be configured separately to be available under the defined path. When using side-by-side deployment, the path must be the same between the primary and secondary deployment.

TLS Settings

If disabled, the TLS related settings are removed from the generated Ingress resource, which means the default certificate provided by NGINX will be used for the TLS termination.

It's only recommended to use this option, when an additional loadbalancer is used in front of NGINX (e.g. Cloudflare), which already provides a valid certificate.

NodePort Service

If enabled, the generated services for the Ingresses will be of type NodePort. This allows direct connection to the nevisProxy instance.

Gateway API Rate Limit Rule​

Max Requests​

Time Period​

Gateway API Settings​

TLS Secrets​

Gateway Class Name​

Gateway Resource Name​

Gateway Resource Namespace​

Key Exchange Algorithms​

Request Timeout​

HTTP Route Filters​

Labels​

Annotations​

Client IP Detection​

Trusted Hops​

Trusted CIDR Ranges​

Action Type​

CIDR Ranges​

Rate Limiting Rules​

Client Cert Authentication​

CA Secret​

CA Secret Namespace​

Path Match Type​

Path Value​

NGINX Ingress Settings​

Annotations​

TLS Secrets​

Ingress Class Name​

Client Cert Authentication​

CA Secret​

CA Secret Namespace​

Client Cert Validation Depth​

Error Page​

Propagate Client Cert​

Path​

TLS Settings​

NodePort Service​

Gateway API Rate Limit Rule

Max Requests

Time Period

Gateway API Settings

TLS Secrets

Gateway Class Name

Gateway Resource Name

Gateway Resource Namespace

Key Exchange Algorithms

Request Timeout

HTTP Route Filters

Labels

Annotations

Client IP Detection

Trusted Hops

Trusted CIDR Ranges

Action Type

CIDR Ranges

Rate Limiting Rules

Client Cert Authentication

CA Secret

CA Secret Namespace

Path Match Type

Path Value

NGINX Ingress Settings

Annotations

TLS Secrets

Ingress Class Name

Client Cert Authentication

CA Secret

CA Secret Namespace

Client Cert Validation Depth

Error Page

Propagate Client Cert

Path

TLS Settings

NodePort Service