Add federated credentials instructions

[NanaXiong00]

Overview/Summary

Add federated credentials instructions.

This PR fixes/adds/changes/removes

Add secret setup instructions for SP using federated credentials.

Breaking Changes

none

As part of this Pull Request I have

• Read the Contribution Guide and ensured this PR is compliant with the guide
• Checked for duplicate Pull Requests
• Associated it with relevant GitHub Issues or ADO Work Items (Internal Only)
• Ensured my code/branch is up-to-date with the latest changes in the main branch
• Ensured PR tests are passing
• Updated relevant and associated documentation (e.g. Contribution Guide, Docs etc.)

@vhvb1989 for notification.

[AlexanderSehr]

Presumably, this PR is dependent on Azure/bicep-registry-modules#2701

Just creating this comment to make sure the PR is not accidently merged :)

cc: @eriqua

[v-xuto]

@vhvb1989 Please help review this PR.

[vhvb1989]

Presumably, this PR is dependent on Azure/bicep-registry-modules#2701

Just creating this comment to make sure the PR is not accidently merged :)

cc: @eriqua

@AlexanderSehr , Azure/bicep-registry-modules#2701 seems weird. It looks like it is creating a list of modules which takes too long for OIDC. I assume that's because the token gets expired and azure/login@v2 doesn't auto-refresh?

[AlexanderSehr]

Presumably, this PR is dependent on Azure/bicep-registry-modules#2701
Just creating this comment to make sure the PR is not accidently merged :)
cc: @eriqua

@AlexanderSehr , Azure/bicep-registry-modules#2701 seems weird. It looks like it is creating a list of modules which takes too long for OIDC. I assume that's because the token gets expired and azure/login@v2 doesn't auto-refresh?

'Weird' is a strong word 😄 It's a draft PR and @eriqua is working hard to get OIDC working in it 😉

And yes, it seems that if you use a Service Principal for federated credentials, you run into a timeout after 1h. However, this may not be the same if using a managed identity which is being tested in a different branch.

I don't have the details as I've not been working on the code myself, so let's give @eriqua some time to figure the best option out 💪

[vhvb1989]

Presumably, this PR is dependent on Azure/bicep-registry-modules#2701
Just creating this comment to make sure the PR is not accidently merged :)
cc: @eriqua

@AlexanderSehr , Azure/bicep-registry-modules#2701 seems weird. It looks like it is creating a list of modules which takes too long for OIDC. I assume that's because the token gets expired and azure/login@v2 doesn't auto-refresh?

'Weird' is a strong word 😄 It's a draft PR and @eriqua is working hard to get OIDC working in it 😉

And yes, it seems that if you use a Service Principal for federated credentials, you run into a timeout after 1h. However, this may not be the same if using a managed identity which is being tested in a different branch.

I don't have the details as I've not been working on the code myself, so let's give @eriqua some time to figure the best option out 💪

You are totally right. I shouldn't have said weird. My apologies.

I've added some comments to that PR. I think you pointed out the same thing that I was curious about. The use of OIDC and client-secret for the same gh-action called my attention as an interesting approach. I wonder if there could be a way to use only OIDC for all.

[AlexanderSehr]

Presumably, this PR is dependent on Azure/bicep-registry-modules#2701
Just creating this comment to make sure the PR is not accidently merged :)
cc: @eriqua

@AlexanderSehr , Azure/bicep-registry-modules#2701 seems weird. It looks like it is creating a list of modules which takes too long for OIDC. I assume that's because the token gets expired and azure/login@v2 doesn't auto-refresh?

'Weird' is a strong word 😄 It's a draft PR and @eriqua is working hard to get OIDC working in it 😉
And yes, it seems that if you use a Service Principal for federated credentials, you run into a timeout after 1h. However, this may not be the same if using a managed identity which is being tested in a different branch.
I don't have the details as I've not been working on the code myself, so let's give @eriqua some time to figure the best option out 💪

You are totally right. I shouldn't have said weird. My apologies.

I've added some comments to that PR. I think you pointed out the same thing that I was curious about. The use of OIDC and client-secret for the same gh-action called my attention as an interesting approach. I wonder if there could be a way to use only OIDC for all.

Hey @vhvb1989,
there absolutely is. As said, @eriqua was working on the topic in the background and opened this draft PR after working her way through some misleading docs and performing some much needed tests: Azure/bicep-registry-modules#2757

Aside from some AZ CLI issue that causes the logic to fail refreshing the token, it seems to work very well with a managed identity.

We had a longer chat about the matter yesterday, and it's likely that we'll merge the change in as soon as @eriqua is back (she's currenlty out of office) and enable both the current credential-based as well as the new OIDC approach for authentication (to avoid breaking changes etc.) and after a grace period cut over completely 💪

[eriqua]

Moving to draft as this would require alignment with the actual implementation (still under testing). Ref Azure/bicep-registry-modules#2792 for latest development