Open javierromancsa opened 2 years ago
Thank you @javierromancsa for this feedback! We are looking into this.
@javierromancsa A point of clarification: I am assuming that the person doing the deployment has rights to assign roles to that provided managed identity, at least temporarily during the times of running the deployer tool. Am I correct?
Also, if the managed identity is named <ResourceGroupName>-Identity
, that identity will simply be used. If that works as a workaround, that's great. But, yes, we are working on this.
Thank you Bill, in an azure ESLZ Cloud Adoption Framework enterprise-scale landing zone architecture - Cloud Adoption Framework | Microsoft Docshttps://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/enterprise-scale/architecture#high-level-architecture , I platform eng. Or cloud excellence member is the one that have right to create a Managed identity. The subscription owner or contributor is the one that will use execute the build(azure resources orchestration) using the managed identity provided. The genomics software eng/bioinformatics using the azureoncromwell will have access to execute in the environment and with operator RBAC in the Managed Identity he can use. If customization is need it, like adding access to another storage account that this user has access he can do that. This is call the "principle of least privilege" and it is apply in everywhere possible in an Enterprise environment. They usually use this azure policy that is apply using manage groups to all subscription with the exception of the subscription "identity subscription"
Managed identities and Azure Policyhttps://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/managed-identities-faq#how-do-i-prevent-the-creation-of-user-assigned-managed-identities
From: Blair L Murri @.> Sent: Friday, November 12, 2021 2:32 AM To: microsoft/CromwellOnAzure @.> Cc: Javier Roman Sanchez @.>; Mention @.> Subject: Re: [microsoft/CromwellOnAzure] add support for BYO azure managed identity (Issue #306)
@javierromancsahttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjavierromancsa&data=04%7C01%7Cjavier.roman%40microsoft.com%7C51408ab2c5db4ddbab3f08d9a5b6f2f2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637723027470327316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cHyHPZaCmMm8JruTdCMHMvOLv73ChdyxzipGbM2m%2FOc%3D&reserved=0 A point of clarification: I am assuming that the person doing the deployment has rights to assign roles to that provided managed identity, at least temporarily during the times of running the deployer tool. Am I correct?
Also, if the managed identity is named
- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2FCromwellOnAzure%2Fissues%2F306%23issuecomment-966917776&data=04%7C01%7Cjavier.roman%40microsoft.com%7C51408ab2c5db4ddbab3f08d9a5b6f2f2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637723027470337311%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1z7bjcSU4k4foZzXBqhDKULr1IvbLHHcdWhdlTfR7G8%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAQCPA425V372EWJT37QYDUDULTGJNANCNFSM5HLVLI2Q&data=04%7C01%7Cjavier.roman%40microsoft.com%7C51408ab2c5db4ddbab3f08d9a5b6f2f2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637723027470337311%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1oJiLI8aDmDhZV1PYRN7gftJyGurTpyKPhMciFb2V%2F0%3D&reserved=0. Triage notifications on the go with GitHub Mobile for iOShttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04%7C01%7Cjavier.roman%40microsoft.com%7C51408ab2c5db4ddbab3f08d9a5b6f2f2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637723027470347303%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bdIn0bBJ0i%2Bh7FsSML6%2BbuxfZmhs2Dtt5k8nLyKY1HY%3D&reserved=0 or Androidhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04%7C01%7Cjavier.roman%40microsoft.com%7C51408ab2c5db4ddbab3f08d9a5b6f2f2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637723027470357298%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oQWe5CxsC8mgtTjfg1qeq9O4V%2F4GmAdE3qb%2Flh%2B%2FUXM%3D&reserved=0.
This is partially implemented. If the MI exists and is named identically to what the deployer would have named it, it does use that MI. However, the deployer does not evaluate already granted role assignments and may fail if duplicate or overlapping roles are assigned.
@BMurri this looks like a long pending issue open since 2021, are we actively working on this or can this be closed?
@ngambani Most (but not all) of the other azure resources in a deployment can be BYO and if a customer needs (for whatever reason) to BYO the MI this is something we should be able to accommodate (within certain bounds).
Working with many Ent. it is very common that the creation of azure managed identities is restricted and controlled by the platform cloud eng. team or Cloud security team, therefore the LoB or department that's trying to deploy this solution/services won't be able to execute it on his own. Very commonly Azure Managed Identities are provided to the LoB or department with Contributor RBAC in order to use them. Alternative the LoB will ask the team with the level of access to do it as temporary approval or "one off" but very unlikely or not prefer and it always delays progress and/or demotivate LoB to procced forward with any current evaluation or POC. Also having the team with higher level of access to execute on a solution/service/code that they haven't vetted is a red flag and security risk for most, if not all azure deployment environment.