You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Originally posted by brianehlert February 13, 2024
NGINX Plus offers a number of capabilities that align with API Gateway use cases.
One of those capabilities is APIKey based authentication.
This would introduce a new APIKey Policy object, the necessary configuration / NJS functions, the ability to associate a key or set of keys with a server or location block, support for VirtualServer and VirtualServerRoute, and a pattern for customers to follow when defining a single or set of APIKeys that is consistent with the NGINX implementation.
NGINX Ingress Controller supports both single and multi-tenant use cases.
In the single tenant use case, one team is responsible for the ingress controller configuration and all of the managed hostnames and paths.
In this case a single team would maintain the secret(s) that contain the key(s) and the header the application supports when passing the key(s) in the request.
In the multi-tenant use case, there might be multiple application teams that define different unique keys for their users, but share a single ingress controller deployment.
It is believed that the complicated workflow is supporting how customers allocate and assign key(s) in a way that is compatible with Kubernetes and that allows the customer to segment key management among multiple teams.
The ingress controller should not be a key management system itself. It should not generate or assign keys, but rather support the use if APIKeys as a method of enforcement for allow/deny of access to server and location blocks.
Discussed in #5089
Originally posted by brianehlert February 13, 2024
NGINX Plus offers a number of capabilities that align with API Gateway use cases.
One of those capabilities is APIKey based authentication.
This would introduce a new APIKey Policy object, the necessary configuration / NJS functions, the ability to associate a key or set of keys with a server or location block, support for VirtualServer and VirtualServerRoute, and a pattern for customers to follow when defining a single or set of APIKeys that is consistent with the NGINX implementation.
NGINX Ingress Controller supports both single and multi-tenant use cases.
In the single tenant use case, one team is responsible for the ingress controller configuration and all of the managed hostnames and paths.
In this case a single team would maintain the secret(s) that contain the key(s) and the header the application supports when passing the key(s) in the request.
In the multi-tenant use case, there might be multiple application teams that define different unique keys for their users, but share a single ingress controller deployment.
It is believed that the complicated workflow is supporting how customers allocate and assign key(s) in a way that is compatible with Kubernetes and that allows the customer to segment key management among multiple teams.
The ingress controller should not be a key management system itself. It should not generate or assign keys, but rather support the use if APIKeys as a method of enforcement for allow/deny of access to server and location blocks.
Initial Policy proposal:
(imagine the values are base64 strings)
Additional suggestions and learnings can be extracted from: https://docs.nginx.com/nginx-management-suite/acm/how-to/policies/apikey-authn/#create-an-api-key-authentication-policy which contains some good high value options.
A consideration needs to be made for supporting multiple APIKeys on a single server or location.
The text was updated successfully, but these errors were encountered: