Skip to content

feat(ai-gateway): add x-api-key SecurityPolicy on the shared Gateway - #69

Closed
atharvamhaske wants to merge 1 commit into
mainfrom
feat/ai-gateway-apikey
Closed

atharvamhaske wants to merge 1 commit into
mainfrom
feat/ai-gateway-apikey

Conversation

@atharvamhaske

@atharvamhaske atharvamhaske commented Sep 21, 2026 •

Copy link
Copy Markdown
Contributor

What this PR does

The chart can attach one Envoy SecurityPolicy to the shared AI Gateway.

Clients send x-api-key. A missing or unknown key returns HTTP 401.

You create the Secret first. Helm does not generate keys.

aiGateway:
  enabled: true
  auth:
    enabled: true
    existingSecretName: ai-gateway-keys

The template is charts/provider-kserve/templates/ai-gateway-auth.yaml.
The rendered name is *-apikey. It only does apiKeyAuth.

Why auth is off by default

The default is aiGateway.auth.enabled: false so Tilt and helm install still work when no Secret exists.

That is convenience. A public LoadBalancer then has no key.

Follow-up: default auth on, or fail install when the Gateway Service is LoadBalancer and auth is off.

Local vs prod

Local and prod use the same Secret shape. Each key is a client id. Each value is an API key.
Helm only stores existingSecretName. There is no second chart path.

Local (Tilt / make): create the Secret before Helm. A short dummy value is fine for a laptop cluster.

KEY=$(openssl rand -base64 32)
kubectl create secret generic ai-gateway-keys --from-literal=tilt="$KEY"

You can print $KEY and send it in x-api-key on curl. The key can live in Tilt logs.

Prod: create the same Secret with a long random value. Use openssl or a vault.
Put the Secret in the cluster. Then give Helm only the Secret name.

Do not put the key in git, in values.yaml, or in the chart.
A dummy string like replace-me is not for prod.

What this does not cover

  • TLS does not require an API key in this PR.
  • A LoadBalancer or port-forward to the model pod skips the Gateway, so this policy does not apply.
  • Per-model keys.

Test plan

  1. Create an Opaque Secret in the release namespace. Each key is a client id. Each value is an API key.
  2. Set aiGateway.enabled=true, aiGateway.auth.enabled=true, and aiGateway.auth.existingSecretName to that Secret name.
  3. Send a request with no x-api-key. The Gateway must return HTTP 401.
  4. Send a request with a valid x-api-key. The Gateway must not return HTTP 401.

Render a SecurityPolicy when `aiGateway.auth.enabled` is true and
`aiGateway.auth.existingSecretName` names an Opaque Secret. Clients
send `x-api-key`. JWT and OIDC stay out of the chart.
@atharvamhaske

Copy link
Copy Markdown
Contributor Author

@spron-in what you think on this ?

@atharvamhaske atharvamhaske changed the title feat(ai-gateway): add opt-in API-key auth on the shared Gateway feat(ai-gateway): add x-api-key SecurityPolicy on the shared Gateway Sep 30, 2026
@spron-in

spron-in commented Oct 6, 2026

Copy link
Copy Markdown
Contributor

superseded by #71

@spron-in spron-in closed this Oct 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants