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

Allow system key to be managed in similar ways as host keys #4728

Closed
sandeepiiit opened this issue Jul 29, 2019 · 5 comments
Closed

Allow system key to be managed in similar ways as host keys #4728

sandeepiiit opened this issue Jul 29, 2019 · 5 comments
Assignees

Comments

@sandeepiiit
Copy link

sandeepiiit commented Jul 29, 2019

It would be nice if system keys for a function app:
1. Can be set to a user-provided value.
2. Can be renewed & revoked.
3. Can be managed through the portal.

1st feature is the one I care about the most.

Problem

I have two function apps (with same code) in two different azure regions. There is an Azure Front Door service that load balances the http traffic (REST api). Users from region A get directed to function app in region A, and users from region B get directed to function app in region B. Also, if one region is down, front door will direct traffic to other.
The app(s) also have a function with EventGrid trigger that does some background work. At present, I can either subscribe them both to events or only one. If I subscribe one, then my service is degraded if that region goes down. If I subscribe them both, then each event is received by both (redundant, but I would prefer to not have to deal with duplicate events).

It would be nice, if I was able to register the function app through it's front door url, and then front door can take care of routing. So if one of the two apps is down, front door takes care of routing it to the one that is up. If both are up, only one of gets a specific event, so no need to worry about duplicates.

However, it is currently not possible to subscribe such load balanced function apps via their front door url because each function app has a unique system key.

Solution

If the system key supports a user specified value (host keys support this), then I can configure both function apps with the same system key, and then front door can be easily used in front. For example, one can register below url as a webhook endpoint in event grid subscription:
https://<frontdoorurl>/runtime/webhooks/eventgrid?functionName={functionname}&code={mysystemkey}
Now, when the front door routes an event to any of the two apps, it still works because they share the same system key.

Alternative

For my particular case, one alternative is to use a HTTPTrigger function to handle events:
https://docs.microsoft.com/en-us/azure/azure-functions/functions-bindings-event-grid#use-an-http-trigger-as-an-event-grid-trigger
However, this means I will have to write some boiler plate code that is not needed in EventGridTrigger functions (like managing subscription endpoint validation)

@jcbrooks92
Copy link

The new ARM APIs support setting your own system key:

Github issue that was tracking the workitem which is now resolved
#3994 (comment)

ARM Template example : https://github.com/jcbrooks92/EventGridAzureFunctionARMTemplate/blob/a5f6815625311a3beb45ea67dc934a3b65594649/azuredeploy.json#L181

@sandeepiiit
Copy link
Author

sandeepiiit commented Jul 30, 2019

Thanks. I haven't tried that yet, but I think it should solve my problem. It would be awesome if the portal also supported this (in the same way it does for host keys, and function keys).

@brettsam
Copy link
Member

brettsam commented Aug 5, 2019

@alrod -- this should be do-able with our APIs today, right?

@sandeepiiit
Copy link
Author

Thanks for the suggestions. I was able to set the system key using the REST API described here:
https://github.com/Azure/azure-functions-host/wiki/Key-management-API

Specifically, I used:

PUT /admin/host/systemkeys/{keyname}?code={masterKey}
{
  "name": "keyname",
  "value" : "keyvalue"
}

For eventgrid, keyname=eventgrid_extension.

@alrod
Copy link
Member

alrod commented Aug 20, 2019

Closing as workaround is found.

@alrod alrod closed this as completed Aug 20, 2019
@msftbot msftbot bot locked as resolved and limited conversation to collaborators Dec 31, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants