question

RobBowman147 avatar image
0 Votes"
RobBowman147 asked PramodValavala-MSFT commented

AzFunc to AzFunc System Managed Identity Call

I have azure function A which needs to call azure function B via an http request. Currently, this is secured by a function key on function B. This works well but I'd like to secure function B using "system assigned" managed identity instead.

What I've tried:

  • Enabled system assigned managed identity on function A

  • On function B, used the portal to add a role assignment of Contributor for a service principal with the name of function A

When function A calls function B, a 401 unauthorised error is returned. Have I missed a step? Do I need to wait 24 hours from adding the role assignment before I can be sure it will take effect? I had hoped to be able to make this work without adding code to function A to obtain and present the bearer token.



azure-functionsazure-managed-identity
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

1 Answer

PramodValavala-MSFT avatar image
1 Vote"
PramodValavala-MSFT answered PramodValavala-MSFT commented

@RobBowman-8564 Azure Functions are protected by Azure RBAC and instead you will need to setup your function to be protected by Azure AD. Then you will provide access to the managed identity of Function A to call Function B.


· 7
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Thanks @PramodValavala-MSFT - the client credentials grant flow seems to be what I need

0 Votes 0 ·

The links given are helpful but don't answer the question. Following the instruction in the links, I have been able to configure a client daemon app that is able to call a service on its own behalf. However, it must present a client id and client secret to the /token endpoint of AAD in order to obtain the OAuth2 access token.

This makes no use of managed identity and means I need to ensure the security of the client secret of the daemon app. If the client id and secret of this app were to fall into the wrong hands, there's nothing to prevent a bad actor obtaining an access token and calling the target service.

I realise that a certificate can be used instead of a client secret but my question to determine if this could be avoided through the use of managed identity of the client daemon app?

0 Votes 0 ·

@RobBowman147 My bad. I should've stated this out before. You can still use Managed Identity and would just need to follow the second half of the section that I've linked which talks about app roles for authorization.

0 Votes 0 ·

@PramodValavala-MSFT thanks again for your answer. It seems the "standard" way, as documented by the links doesn't use managed identity. It also requires custom code for authorization of an app role so that it remains secure in the event the client secret is compromised.

Use of managed identity for one app service calling another is documented here. This solution suggests no client secret needs to be created. Unfortunately, it seems this is not yet supported via the portal.


0 Votes 0 ·
Show more comments