Sets Azure Storage authentication method from Access Key to Entra User Account

[bronius]

Description

Since we don't want to access Azure Storage for terraform backend storage via Access Keys, I had to do a little dance to enable Entra User Authentication.

• I don't know if this is the right approach to solve the issue
• It's also WIP, because I have temporarily set the new role principal_id to a group that my az-cli user is a member of for convenience, but either we need a more appropriate group or some other approach.

Another idea is to create and apply a Managed Identity. Would this work for "anyone running the parent terraform" (who ultimately needs access to read tfstate stored in the container).

Update: Each of the commits on this PR is another slightly different stab and none better than the previous. I fail to end up with an idempotent (can rerun apply and either first-time create or detect no differences) outcome: I always get either duplicate resources:

or failure:

or failure:

I am probably out of ideas. What I am going for is:

• Storing remote backend in Azure Storage
• That can be accessed by Entra User Access (without Access Keys)
• By a developer running the parent terraform script. I'd even settle from just me running that parent terraform script.

[joraff]

https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles/privileged#owner

Owner's DataActions == none. Simply having the Owner role assignment over the entire subscription does not grant you any permissions to access the data as an Entra ID user. Viable role assignments listed here: https://learn.microsoft.com/en-us/azure/storage/blobs/assign-azure-role-data-access

(TIL)

[bronius]

Alright, I'll play a bit more: Maybe I've been and continue to be bitten by "can take up to 10 minutes" (but not likely the "up to 12 hours") bullet points in the second Learning article you linked. Further, I wonder if using such privileged account affects that "time delay," meaning a less privileged user might be more instantaneous...? I'll start with working from the subscription access mentioned. That would be ideal anyway, I think. Thanks..!

…

On Tue, Nov 12, 2024, 1:14 AM Joseph Rafferty ***@***.***> wrote: https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles/privileged#owner Owner's DataActions == none. Simply having the Owner role assignment over the entire subscription does not grant you any permissions to access the data as an Entra ID user. Viable role assignments listed here: https://learn.microsoft.com/en-us/azure/storage/blobs/assign-azure-role-data-access (TIL) — Reply to this email directly, view it on GitHub <#5 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAR5KZX32NEBLJOW6EK5OW32AGTE5AVCNFSM6AAAAABRSEFM72VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRZG43DIOBZHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[bronius]

@joraff Ready for your eyes again. See my string of commits/messages and where I ultimately landed 8ddb05a.

Please review for:

• "Do not do it like that"
• Prefer to do it like ... or did you try like..
• Portability of code sample provided in this feature branch README update, considering my assumption that this module is for our own multi-env terraform scenario which we developed
• And whatever changes you prescribe are for this PR vs a future enhancement (for which I'd like to see an issue instead)

Note that this resumes idempotency of the module.

I plan to use this commit in actual project work in the meantime, because it has finally given me the distance I needed.

Update LOL: I see that after all the string of experimentation, I did not actually change codebase other than to add one more convenience terraform output.