docs: adding conceptual pages for high priority concepts #7323
+402
−0
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,57 @@ | ||
| --- | ||
| title: "API Security" | ||
| --- | ||
|
|
||
| ## Overview | ||
|
|
||
| API security protects applications and services from unauthorized access, data breaches, and abuse. In Envoy Gateway, API security includes mechanisms for authentication, authorization, rate limiting, encryption, and access control at the edge of your infrastructure. | ||
|
|
||
| Envoy Gateway extends the Kubernetes Gateway API with features such as `SecurityPolicy`, allowing declarative and Kubernetes-native configuration of security requirements. This model ensures that only authenticated and authorized requests reach backend services, providing a consistent and auditable way to address modern API threats. | ||
|
|
||
| ## Key Concepts | ||
|
|
||
| | Concept | Summary | | ||
| |-----------------------------|-----------------------------------------------------------------------------------------| | ||
| | Authentication | Verifies client identity using mechanisms such as API keys, JWTs, Basic Auth, mTLS, and OIDC. | | ||
| | Authorization | Controls access to resources based on user roles, JWT claims, or external services. | | ||
| | Access Control | IP allowlist/denylist to restrict or permit access from specific addresses. | | ||
| | SecurityPolicy CRD | Defines authentication, authorization, and encryption settings for Gateway API resources.| | ||
| | Rate Limiting | Limits requests to protect APIs from abuse; supports global and local enforcement. | | ||
| | CORS | Configurable policies to allow or restrict cross-origin API requests. | | ||
|
|
||
| ## Use Cases | ||
|
|
||
| Use API security to: | ||
|
|
||
| - Authenticate and authorize client access to APIs. | ||
| - Restrict API access based on IP allowlist/denylist. | ||
| - Enforce rate limiting to protect APIs from abuse. | ||
| - Apply CORS policies to control cross-origin API requests. | ||
| - Encrypt traffic with TLS and manage certificate securely. | ||
|
|
||
| ## API Security in Envoy Gateway | ||
|
|
||
| API security is implemented through Kubernetes-native policies and Envoy Gateway API extensions. The core mechanism is the [SecurityPolicy](./../concepts/gateway_api_extensions/security-policy.md) Custom Resource Definition (CRD), which defines how authentication, authorization, and encryption are applied to incoming traffic. Policies attach to Gateway API resources (such as Gateways, HTTPRoutes, or GRPCRoutes) using `targetRefs` or `targetSelectors`. The most specific policy applies when multiple policies target the same resource. | ||
|
|
||
| Envoy Gateway supports API key, JWT, mTLS, Basic Auth, and OIDC authentication; authorization via external services or JWT claims; access control with IP allow/deny lists; CORS configuration; and rate limiting. This model enables secure, declarative access control at the edge, aligning with Kubernetes best practices. | ||
|
|
||
|
There was a problem hiding this comment. can we add a link to SecurityPolicy concepts as well https://gateway.envoyproxy.io/docs/concepts/gateway_api_extensions/security-policy/ |
||
| ## Examples | ||
|
|
||
| - Attach a `SecurityPolicy` with JWT authentication to an `HTTPRoute`. | ||
| - Configure CORS on a Gateway listener using a `SecurityPolicy`. | ||
| - Enforce global or local rate limiting using `BackendTrafficPolicy`. | ||
| - Restrict access to APIs using IP allowlist/denylist in `SecurityPolicy`. | ||
|
|
||
| ## Related Resources | ||
|
|
||
| - [API Key Authentication](../tasks/security/apikey-auth.md) | ||
| - [Basic Authentication](../tasks/security/basic-auth.md) | ||
| - [CORS](../tasks/security/cors.md) | ||
| - [External Authorization](../tasks/security/ext-auth.md) | ||
| - [IP Allowlist/Denylist](../tasks/security/restrict-ip-access.md) | ||
| - [JWT Authentication](../tasks/security/jwt-authentication.md) | ||
| - [JWT Claim Based Authorization](../tasks/security/jwt-claim-authorization.md) | ||
| - [OIDC Authorization](../tasks/security/oidc.md) | ||
| - [SecurityPolicy API Reference](../api/extension_types#securitypolicy) | ||
|
|
||
|
|
||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,49 @@ | ||
| --- | ||
| title: "Authentication" | ||
| --- | ||
|
|
||
| ## Overview | ||
|
|
||
| Authentication in Envoy Gateway ensures that only verified users or systems can access backend services. By validating credentials such as tokens, certificates, or keys before forwarding requests, Envoy Gateway provides a secure boundary for workloads running in Kubernetes. | ||
|
|
||
| Authentication is configured using the `SecurityPolicy` Custom Resource Definition (CRD), which allows you to define authentication requirements for traffic entering your gateway and attach policies to Gateway API resources. | ||
|
|
||
|
|
||
| ## Key Concepts | ||
|
|
||
| | Concept | Description | | ||
| |------------------------|---------------------------------------------------------------------------------------------------| | ||
| | Authentication Methods | Envoy Gateway supports mTLS, JWT, API keys, Basic Auth, and OIDC authentication methods. | | ||
| | SecurityPolicy CRD | The main CRD for configuring authentication and authorization, attached via `targetRefs` or `targetSelectors`.| | ||
| | Policy Attachment | Authentication policies are attached to Gateway API resources (e.g., Gateway, HTTPRoute, GRPCRoute).| | ||
|
|
||
|
|
||
| ## Use Cases | ||
|
|
||
| Use Authentication to: | ||
| - Authenticate client applications using mTLS, JWT, API keys, or Basic Auth. | ||
| - Integrate with OIDC providers for user authentication. | ||
| - Enforce access controls at the edge for APIs and services. | ||
|
|
||
|
|
||
| ## Implementation | ||
|
|
||
| Envoy Gateway expresses authentication using the `SecurityPolicy` CRD, an extension to the Kubernetes Gateway API. The `SecurityPolicy` defines authentication requirements and is attached to Gateway API resources through `targetRefs` or `targetSelectors`. Supported authentication methods include mTLS, JWT, API keys, Basic Auth, and OIDC. | ||
|
|
||
|
|
||
| ## Examples | ||
|
|
||
| - Attach a `SecurityPolicy` to an `HTTPRoute` to require JWT authentication from the `Authorization` header. | ||
| - Store Basic Auth credentials in a Kubernetes secret and reference them in a `SecurityPolicy`. | ||
| - Use a local JWKS via Kubernetes ConfigMap for JWT validation in a `SecurityPolicy`. | ||
| - Configure OIDC authentication at the Gateway or HTTPRoute level with a `SecurityPolicy`. | ||
|
|
||
|
|
||
| ## Related Resources | ||
|
|
||
| - [JWT Authentication Task (latest)](https://gateway.envoyproxy.io/latest/tasks/security/jwt-authentication/) | ||
| - [JWT Authentication User Guide (v0.6)](https://gateway.envoyproxy.io/v0.6/user/jwt-authentication/) | ||
| - [Gateway API HTTPRoute Documentation](https://gateway-api.sigs.k8s.io/api-types/httproute/) | ||
| - [Envoy JWT Authentication Filter Reference](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/jwt_authn_filter#config-http-filters-jwt-authn) | ||
| - [JSON Web Token (JWT) RFC 7519](https://tools.ietf.org/html/rfc7519) | ||
| - [JSON Web Key Set (JWKS) RFC 7517](https://tools.ietf.org/html/rfc7517) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,32 @@ | ||
| --- | ||
| title: "Authorization" | ||
| --- | ||
|
|
||
|
|
||
| ## Overview | ||
| Authorization controls what an authenticated identity is allowed to do. Envoy Gateway supports both local RBAC and external authorization integrations. | ||
|
|
||
| ## Key Concepts | ||
|
|
||
| | Concept | Description | | ||
| |----------|--------------| | ||
| | RBAC | Role-based access control rules for routes or clusters. | | ||
| | External AuthZ | Delegates authorization to an external service. | | ||
| | Policy | Defines access rules for requests (allow/deny). | | ||
|
|
||
| ## Use Cases | ||
| - Restrict access to `/admin` routes. | ||
| - Apply route-level access control. | ||
| - Integrate with an external OPA or custom AuthZ service. | ||
|
|
||
| ## Implementation | ||
| `SecurityPolicy` resources are implemented using Envoy RBAC and `ext_authz` filters, evaluated per request. | ||
|
|
||
| ## Examples | ||
| - Deny all except specific IPs. | ||
| - Use an external OPA server. | ||
| - Apply per-route RBAC policies. | ||
|
|
||
| ## Related Resources | ||
|
|
||
| - [External Authorization Reference](./../tasks/security/ext-auth.md) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,106 @@ | ||
| --- | ||
| title: "Circuit Breaking" | ||
| --- | ||
|
|
||
| ## Overview | ||
|
|
||
| Circuit breaking is a resilience mechanism used to prevent system overload and quickly fail requests when upstream services are degraded or unresponsive. By defining thresholds for concurrent connections, concurrent requests, and pending requests, circuit breakers help maintain system stability and apply back-pressure to protect backend services. | ||
|
|
||
| Envoy Gateway leverages circuit breaking to limit resource consumption and ensure reliable traffic handling. Through configurable thresholds and integration with Kubernetes via the BackendTrafficPolicy custom resource, users can fine-tune circuit breaking behavior to fit their specific resilience and performance requirements. | ||
|
|
||
| ## Key Concepts | ||
|
|
||
| | Concept | Description | | ||
| | ---------------------------- | ------------------------------------------------------------------------------------------------------ | | ||
| | **Circuit Breaker** | A safety control that limits the number of concurrent or pending requests sent to an upstream service. | | ||
| | **BackendTrafficPolicy CRD** | Configures circuit breaking thresholds for Gateway API resources. | | ||
| | **Concurrent Connections** | Maximum number of active connections Envoy can maintain with an upstream service. | | ||
| | **Concurrent Requests** | Maximum number of in-flight requests permitted to a backend. | | ||
| | **Pending Requests** | Maximum size of the request queue; requests beyond this limit return `503`. | | ||
|
|
||
|
|
||
|
|
||
| ## Use Cases | ||
|
|
||
| Use circuit breaking to: | ||
|
|
||
| - Protect backend services from overload by limiting concurrent connections, requests, and pending requests. | ||
| - Fail fast and apply back-pressure when upstream services are degraded or unresponsive. | ||
| - Improve system resilience by isolating failing backends and preventing cascading failures. | ||
|
|
||
| ## Circuit Breaking in Envoy Gateway | ||
|
|
||
| Envoy Gateway implements circuit breaking through the `BackendTrafficPolicy` Custom Resource, which defines per-backend thresholds for traffic flow control. | ||
|
|
||
| - Policies can target `Gateway`, `HTTPRoute`, or `GRPCRoute` resources using `targetRefs` or `targetSelectors`. | ||
|
|
||
| - Each backend reference in a route has its own independent circuit breaker counters, preventing one failing service from impacting others. | ||
|
|
||
| - Default thresholds (1024 connections/requests) are conservative and should be tuned for high-throughput systems. | ||
|
|
||
| - Circuit breaker counters are distributed, meaning they are not synchronized across Envoy instances. | ||
|
|
||
| ## Examples | ||
|
|
||
| - Limit concurrent requests and pending requests for a route: | ||
|
|
||
| ```yaml | ||
| apiVersion: gateway.envoyproxy.io/v1alpha1 | ||
| kind: BackendTrafficPolicy | ||
| metadata: | ||
| name: circuitbreaker-for-route | ||
| spec: | ||
| targetRefs: | ||
| - group: gateway.networking.k8s.io | ||
| kind: HTTPRoute | ||
| name: backend | ||
| circuitBreaker: | ||
| maxPendingRequests: 0 | ||
| maxParallelRequests: 10 | ||
| ``` | ||
|
|
||
| - Apply circuit breaking to all routes in a Gateway, with a maximum of 100 connections: | ||
|
|
||
| ```yaml | ||
| apiVersion: gateway.envoyproxy.io/v1alpha1 | ||
| kind: BackendTrafficPolicy | ||
| metadata: | ||
| name: gateway-policy | ||
| spec: | ||
| targetRefs: | ||
| - kind: Gateway | ||
| name: my-gateway | ||
| circuitBreaker: | ||
| maxConnections: 100 | ||
| ``` | ||
|
|
||
| - Set a lower maximum connection count for a specific HTTPRoute: | ||
|
|
||
| ```yaml | ||
| apiVersion: gateway.envoyproxy.io/v1alpha1 | ||
| kind: BackendTrafficPolicy | ||
| metadata: | ||
| name: route-policy | ||
| spec: | ||
| targetRefs: | ||
| - kind: HTTPRoute | ||
| name: my-route | ||
| circuitBreaker: | ||
| maxConnections: 50 | ||
| ``` | ||
|
|
||
| ## Related Resources | ||
|
|
||
| - [Circuit Breakers](../tasks/traffic/circuit-breaker.md) | ||
| - [BackendTrafficPolicy API Reference](../api/extension_types#backendtrafficpolicy) | ||
| - [Gateway](https://gateway-api.sigs.k8s.io/api-types/gateway/) | ||
| - [HTTPRoute](https://gateway-api.sigs.k8s.io/api-types/httproute/) | ||
| - [GRPCRoute](https://gateway-api.sigs.k8s.io/api-types/grpcroute/) | ||
| - [Envoy Circuit Breakers](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/circuit_breaking) | ||
| - [Failover](../tasks/traffic/failover) | ||
| - [Fault Injection](../tasks/traffic/fault-injection) | ||
| - [Global Rate Limit](../tasks/traffic/global-rate-limit) | ||
| - [Local Rate Limit](../tasks/traffic/local-rate-limit) | ||
| - [Load Balancing](../tasks/traffic/load-balancing) | ||
| - [Response Compression](../tasks/traffic/response-compression) | ||
| - [Response Override](../tasks/traffic/response-override) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,46 @@ | ||
| --- | ||
| title: " Extensibility Options" | ||
| --- | ||
|
|
||
| ## Overview | ||
| Envoy Gateway can be extended to support custom logic and integrations through filters, external processors, and WebAssembly modules. | ||
|
There was a problem hiding this comment. can we copy some of https://gateway.envoyproxy.io/docs/tasks/extensibility/ to this page, thinking out loud, is the concepts page needed now we have more data in the tasks page |
||
|
|
||
| Envoy Gateway exposes extension hooks via its configuration APIs. | ||
| Depending on the extension model, custom modules can be: | ||
|
|
||
| - **Loaded dynamically** inside Envoy (for WASM and Lua). | ||
| - **Invoked remotely** via gRPC (for external processors). | ||
| - **Integrated through translation layers** (for patch policy or extension server). | ||
|
|
||
| This design keeps the control plane declarative and extensible while maintaining Envoy’s runtime performance and isolation guarantees. | ||
|
|
||
| ## Key Concepts | ||
|
|
||
| | Concept | Description | | ||
| |----------|--------------| | ||
| | Filters | Processing units in request/response path. | | ||
| | [External Processors](./../tasks/extensibility/ext-proc.md) | Run custom logic in out-of-process services. | | ||
| | [WebAssembly](./../tasks/extensibility/wasm.md) | Execute sandboxed plugins inside Envoy. | | ||
| | [Lua Extensions](./../tasks/extensibility/lua.md) | Lightweight scripting support within Envoy configuration for quick customizations without rebuilding the proxy. | Simple request manipulation or header injection. | | ||
| | [Extension Server](./../tasks/extensibility/extension-server.md) | Mechanisms to directly modify or transform Envoy xDS configuration during translation. Useful for advanced or unsupported features. | Injecting Envoy-native features not yet supported by Envoy Gateway APIs. | | ||
|
|
||
| ## Use Cases | ||
| Different extension methods suit different needs: | ||
|
|
||
| - **For inline logic** close to the data path → use **Filters** or **WASM**. | ||
| - **For complex or external integrations** → use **External Processing**. | ||
| - **For rapid prototyping or scripting** → use **Lua**. | ||
| - **For deep Envoy configuration access** → use **Patch Policy** or **Extension Server**. | ||
|
|
||
| ## Implementation | ||
| Envoy Gateway exposes extension hooks via configuration APIs. Custom extensions can be loaded dynamically through WASM or external processors. | ||
|
|
||
| ## Examples | ||
| - Add custom authentication or JWT validation logic. | ||
| - Transform or sanitize headers before routing. | ||
| - Implement dynamic routing for A/B testing. | ||
| - Enrich telemetry data with external metadata. | ||
| - Prototype new traffic management features via Lua. | ||
|
|
||
| ## Related Resources | ||
| - [Extension Options](./../tasks/extensibility/_index.md) | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,49 @@ | ||
| --- | ||
| title: "Observability" | ||
| --- | ||
|
|
||
|
|
||
| ## Overview | ||
|
|
||
| Observability in Envoy Gateway provides comprehensive insight into both the control plane and Envoy Proxy instances. It allows users to collect, monitor, and analyze metrics, logs, and traces to ensure system health, optimize performance, and troubleshoot issues efficiently. | ||
|
|
||
| Envoy Gateway leverages standards like Prometheus and OpenTelemetry to export metrics and supports integration with external observability tools such as Grafana and Jaeger. Observability features are configurable to meet diverse operational requirements, empowering operators with actionable visibility across their infrastructure. | ||
|
|
||
| ## Key Concepts | ||
|
|
||
| | Concept | Description | | ||
| |--------------|-------------| | ||
| | Metrics | Quantitative data from Envoy Gateway and Envoy Proxy. Supports Prometheus (pull) and OpenTelemetry (push) sinks. Includes counters, gauges, histograms, and labels for component/resource identification. | | ||
| | Logs | Structured logs from the Envoy Gateway control plane, managed by an internal zap-based library and written to `/dev/stdout`. Logging levels can be configured per component. | | ||
| | Traces | Distributed tracing using OpenTelemetry, Zipkin, or Datadog tracers. Configurable via the EnvoyProxy CRD with support for sampling rate and custom tags. | | ||
| | Runners | Core telemetry sources: Resource Provider, xDS Translator, Infra Manager, xDS Server, Status Updater. Each emits labeled metrics to support monitoring and troubleshooting. | | ||
|
|
||
| ## Use Cases | ||
|
|
||
| Use observability in Envoy Gateway to: | ||
|
|
||
| - Monitor control plane health and proxy behavior. | ||
| - Troubleshoot latency, errors, and traffic anomalies. | ||
| - Integrate with external tools like Prometheus, Grafana, and OpenTelemetry Collector. | ||
| - Enable auditing and compliance via centralized logging. | ||
| - Set up real-time alerting and dashboards with Prometheus and OpenTelemetry metrics. | ||
|
|
||
| ## Observability in Envoy Gateway | ||
|
|
||
| Envoy Gateway implements observability as a core capability, covering metrics, logs, and traces, all of which can be surfaced via standard interfaces and integrated with external platforms. Metrics are collected from key components (Resource Provider, xDS Translator, Infra Manager, Status Updater, xDS Server) and exported to Prometheus or pushed to OpenTelemetry. Logging is written to standard output, with configurable verbosity. Distributed tracing is supported for OpenTelemetry, Zipkin, and Datadog tracers (OpenTelemetry is currently supported), with configuration at the EnvoyProxy CRD level. This ensures deep visibility into both Envoy Gateway’s operations and the traffic handled by Envoy Proxy instances. | ||
|
|
||
| ## Examples | ||
|
|
||
| - Query Envoy Gateway metrics using Prometheus by port-forwarding to the Prometheus service and running a `curl` command against the `/api/v1/query` endpoint. | ||
| - Disable Prometheus metrics in EnvoyProxy by setting `telemetry.metrics.prometheus.disable` to `true` in the EnvoyProxy CRD. | ||
| - Configure Envoy Gateway to export metrics to an OpenTelemetry Collector by specifying a sink of type `OpenTelemetry` in the EnvoyProxy resource. | ||
| - Enable the debug exporter in the OpenTelemetry Collector to view raw metrics output in pod logs. | ||
|
|
||
| ## Related Resources | ||
|
|
||
| - [Proxy Metrics (latest)](https://gateway.envoyproxy.io/latest/tasks/observability/proxy-metric/) | ||
| - [Grafana Integration](https://gateway.envoyproxy.io/latest/tasks/observability/grafana-integration/) | ||
| - [Gateway Exported Metrics List](https://gateway.envoyproxy.io/latest/tasks/observability/gateway-exported-metrics/) | ||
| - [Addons Helm Chart Installation Guide](https://gateway.envoyproxy.io/docs/install/gateway-addons-helm-api/) | ||
| - [OpenTelemetry](https://opentelemetry.io/) | ||
| - [Envoy Admin Endpoint Documentation](https://www.envoyproxy.io/docs/envoy/latest/operations/admin) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,32 @@ | ||
| --- | ||
| title: "Sessions" | ||
| --- | ||
|
|
||
| ## Overview | ||
| Session management maintains continuity across multiple client requests. While Envoy is stateless by default, Envoy Gateway supports session persistence for sticky connections. | ||
|
|
||
| ## Key Concepts | ||
|
There was a problem hiding this comment. can we link out to tasks for each of these - session Persistence, load balancing with consistent hash There was a problem hiding this comment. and explain the concepts of strong and weak affinity |
||
|
|
||
| | Concept | Description | | ||
| |----------|--------------| | ||
| | [Session Persistence](./../tasks/traffic/session-persistence.md) | Allows client requests to be consistently routed to the same backend service instance. | | ||
| | Strong Session Affinity | Routes a client’s requests to the same backend. Cookie-based persistence with a permanent cookie. | | ||
| | Weak Session Affinity | Routes to the same backend is not guaranteed. Header-based persistence or cookie persistence with a short TTL. | | ||
| | [Load Balancer State](./../tasks/traffic/load-balancing.md) | Maintains session mappings across connections. | | ||
|
|
||
| ## Use Cases | ||
| - Maintain login state in web applications. | ||
| - Preserve shopping cart data. | ||
| - Improve cache locality in microservices. | ||
|
|
||
| ## Implementation | ||
| Envoy Gateway supports session persistence via cookie-based and consistent-hash load balancing policies defined in `HTTPRoute` configurations. | ||
|
|
||
| ## Examples | ||
| - Enable cookie-based session affinity. | ||
| - Use consistent hashing by header. | ||
| - Route same user to same backend pod. | ||
|
|
||
| ## Related Resources | ||
|
|
||
| - [Load Balancing Reference](load-balancing.md) | ||
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it possible to created a tiered layout for api-security and authn and authnz rather than this flat hierarchy that we have rn ?
cc @missBerg