Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better error handling for KubernetesSecretsRepository #10740

Open
lucadelauw opened this issue Jan 14, 2025 · 1 comment
Open

Better error handling for KubernetesSecretsRepository #10740

lucadelauw opened this issue Jan 14, 2025 · 1 comment

Comments

@lucadelauw
Copy link

lucadelauw commented Jan 14, 2025

What problem would the feature you're requesting solve? Please describe.

Currently when using AzureWebJobsSecretStorageType: kubernetes, one must create at least one access key for each individual function. This can be annoying when making generic deployment pipelines where the pipeline is unaware of the different functions that exist.

When one doesn't create a key for each function, making a request to that function will result in a 500 response code when it should return a 401. I suspect that whenever a request is made, KubernetesSecretsRepository or another component first checks for any valid host key and then for function level keys. Because when I make a request with a valid access key, the request is authorized. However, when the access key is invalid I get a 500 (instead of the expected 401).

When I do create a function level key, I get the expected behavior.

Describe the solution you'd like

Not having an access key for a specific function should be a supported scenario. In my case I would like to only use a key on the host level instead of specific keys for each function.

Additional context

I'll tag @ahmelsayed since you are the original creator of the KubernetesSecretsRepository and might be interested in this or even wanting to implement this yourself 😉

Reproduction steps

When using this Secret object in Kubernetes

kind: Secret
apiVersion: v1
metadata:
  name: functions-key
type: Opaque
stringData:
  host.master: testkey
  functions.<functionname>.default: testkey

we get the expected behavior:
valid 'x-functions-key' header -> 200
no 'x-functions-key' header -> 401
invalid 'x-functions-key' header value -> 401

When we remove the default function key

kind: Secret
apiVersion: v1
metadata:
  name: functions-key
type: Opaque
stringData:
  host.master: testkey

we get the following behavior:
valid 'x-functions-key' header -> 200
no 'x-functions-key' header -> 401
invalid 'x-functions-key' header value -> 500

@lucadelauw
Copy link
Author

Added 'Reproduction steps'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant