Feature: Workload identity federation for Azure

[novakmartin]

Hi, our company is currently tightening security rules and expects employees to use Workload Identity Federation for authentication while interacting with Google APIs. However we are using Microsoft Azure accounts. Would it be possilbe to enhance the WifToken obtaining procedure for other providers?

We are primarily using bigrquery package to interact with Biq Query database.

Best regards, Martin

[jennybc]

When I implemented this for AWS, it was motivated by a company using AWS but also needing to access GCP resources. So their AWS account folks and, I think, a 3rd party consultant were on the case. And those highly motivated folks did lots of setup so that I could sign in to a VM on AWS, with all the federated auth configuration complete for accessing specific GCP resources. I did not have to setup all the bits on the two ends myself (AWS and GCP).

And I did not have to instantiate a VM. I could just sign in to an RStudio Workbench instance and develop the necessary code in gargle.

To be honest, this level of pre-work would be necessary to extend the workload identity federation for Azure. So, it could happen, but I need a lot of support to get into the right position to actually do the work inside gargle.

[jennybc]

@novakmartin If you are a customer of Posit's pro products, that would be worth mentioning. And you would want to bring this to the attention of the folks who handle your Posit account (ditto for Azuer). Could be helpful for creating the pre-conditions described above for feature development.

[novakmartin]

@jennybc Thank you for your comment. I completely understand your standpoint. I contacted our infrastructure department but unfortunately we cannot arrange access for you into our companys system as the project is managing confidential data. Further, we would not recieve corporate resources just to benefit the community. :(

Therefore, I went through your implementation and was able to 'bend' the code written in credentials_external_account.R so it accepts Azure token instead of AWS.

Fortunately, the Azure response has probably similar structure as AWS, so it was not so much work to strip down your AWS checks and feed token generated by:

subject_token <- AzureAuth::get_azure_token(resource = azure_resource, 
                                             tenant = azure_tenant, 
                                             app = azure_app,
                                             auth_type = "authorization_code", 
                                             version = 2 # for work accounts / version = 1 for private
                                              )

The full procedure is published under my account:

https://github.com/novakmartin/wif_azure

I hope it might help you if you ever start working on this feature.

So this probably concludes my request and thank you for your great work.

[jennybc]

OK glad you are unstuck. I'm going to close this but if anyone else comes by interested in same, I'd like to clarify this:

I contacted our infrastructure department but unfortunately we cannot arrange access for you into our companys system as the project is managing confidential data. Further, we would not recieve corporate resources just to benefit the community. :(

In the AWS case, I didn't get access to the system of the company who was inspiring the work. The consultant actually created a sandbox for me -- just enough for me to have an authentic experience of the auth federated auth flow. So, yes, that was some work done by them that benefited the community, but I think one can also frame it ... lots of the auth infrastructure here is coming "for free" and so it's great if some of the beneficiaries occasionally contribute something like this that unblocks the development of a new feature in the open source tool they're using.

With https://github.com/novakmartin/wif_azure it seems like you might be really close to making a PR to gargle. Any chance of that? In any case, thanks for sharing that code.