I would like to find out what the best practices are for managing developers' access to a sub-set of resources on a client's subscription?
I've searched Google and the Azure documentation looking for definitive answers, but I have yet to come across an article that puts it all together. Because Azure is still developing so rapidly I often find it difficult to determine whether a particular article may still be relevant.
To sum up our situation:
I've been tasked with researching and implementing the Azure infrastructure for a web site our company is developing for a client. At the moment our manager and I have access to the client's entire subscription on the Azure Portal by means of the Service Administrator's credentials, even though we're managing only:
Azure Cloud Service running a Web-Role (2-instances with Production and Staging environments).
Azure SQL Database.
Azure Blob Storage for deployments, diagnostics etc.
We're now moving into a phase where more of the developers in the team will require access to perform maintenance type tasks such as performing a VIP swap, retrieving diagnostic info etc.
What is the proper way to manage developer's access on such a project?
The approach I've taken was to implement Role Based Access Control (https://azure.microsoft.com/en-us/documentation/articles/role-based-access-control-configure/)
Move 1, 2, and 3 above into a new Resource Group according to http://blog.kloud.com.au/2015/03/24/moving-resources-between-azure-resource-groups/
Creating a new User Group for our company, say "GroupXYZ".
Adding the "GroupXYZ" to the Contributor role.
Adding the particular developer's company accounts to "GroupXYZ"
Motivation for taking the role-based approach
From what I understand giving everyone access as a Co-Administrator would mean that they have full access to every subscription in the portal.
Account-based authentication is preferable to certificate-based authentication due to the complexity added by managing the certificates.
What caused me to question my approach was the fact that I could not perform a VIP swap against the Cloud Service using PowerShell; I received an error message stating that a certificate could not be found.
Do such role-based accounts only have access to Azure by means of the Resource Manager Commandlets?
I had to switch PowerShell to the Azure Service Manager (ASM) Mode before having access to the Move-AzureDeployment commandlet.
Something else I'm not sure of is whether or not Visual Studio will have access to those resources (in the Resource Group) when using Role Based Access Control.
When you apply RBAC to Azure as you have or just in general, give access to an account via RBAC, then those accounts can only access Azure via the Azure Resource Manager APIs, whether that's PowerShell, REST or VS.
VS 2015 can access Azure resources via RBAC when using the 2.7 SDK. VS 2013 will have support for it soon.
Related
In our organization, we are having common credentials to access the postgres databases, which every developers know, as it is hardcoded in application's connection string. Due to which, whenever a DML/DDL changes happens on databases, it is hard for us trace, as the developers use to make changes on their own. We can't have individual logins for each developers which is tedious to manage.
Note: Also, we can't ensure that the credentials won't be shared with the peer developers.
To get rid of this, we thought of integrating Postgres with Azure Active Directory, for Authentication.
If we can map Azure AD group/users to Postgres, security will be tightened as well as maintenance overhead will also reduce.
But, I couldn't find a article to implement this, since most of the articles says the integration for Azure managed postgresql with Azure AD, and not for the postgres running on VMs.
Can anyone guide me or share a detailed article to implement the Azure AD integration for Postgres running on a VM(IaaS)
In Azure portal go to the postgresql database select Authentication and set active directory admin.
You can specify an Azure AD group instead of an individual user to have multiple administrators.
Connecting to postgresql :
1.Login to Azure subscription.
2.Get the access token of the postgresql serverusing below command:
az account get-access-token --resource https://ossrdbms-aad.database.windows.net
3.Use that token as password for login with postgresql server.
Creating user
CREATE USER "user1#yourtenant.onmicrosoft.com" IN ROLE azure_ad_user;
Token validation:
Token is signed by Azure AD and has not been tampered with
Token was issued by Azure AD for the tenant associated with the server
Token has not expired
Token is for the Azure Database for PostgreSQL resource (and not another Azure resource)
Reference Link: Use Azure Active Directory - Azure Database for PostgreSQL - Single Server | Microsoft Learn
Using Azure Active Directory is a great idea for the reasons you specified, but unfortunately there's no native support for connection to Azure Active Directory with a local Postgres database (which is essentially what you have with Postgres in a VM). It can be done through the LDAP protocol, however.
FULL DISCLOSURE: I haven't actually done this part myself (or used the steps in the tutorial link), but this is my understanding from working with system operators. Use LDAP to connect to Azure AD then Postgres to connect via LDAP. More information on LDAP authentication in Postgres can be found here.
Bhavani's answer is about Azure Database for PostgreSQL, which is a Azure-native database service. This part I have used and I highly recommend it; you get Azure AD integration and can manage the database performance and connectivity specifically without having to also manage VM performance. Note that their screenshot is for the Flexible Server while the reference link says 'Single Server'; I recommend Flexible Server.
We've been told by Microsoft support that Azure DevOps Services supports tenant restrictions. While we have tenant restrictions enabled on a number of other services, it does't seem to apply to DevOps. Not only can we still log in to organizations outside of our tenant, we can also log in to our own organization and, if our corp email is added as a user in that org, the organization also shows up. I'd expect that our users would be blocked from logging into or accessing any external orgs.
I'm a little confused about why this isn't just working as expected and despite them saying Azure DevOps Services supports tenant restrictions, I'm not finding much documentation to back that up.
Have you been able to migrate to Azure DevOps Services and ensure that your users are only able to access orgs within your own tenant? How?
Azure DevOps Service supports the Azure Active Directory (Azure AD) tenant policy to restrict users from creating an organization in Azure DevOps. This policy is turned off, by default. You must be an Azure DevOps Administrator in Azure AD to manage this policy.
Check following link for more details:
https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/azure-ad-tenant-policy-restrict-org-creation?view=azure-devops
Notice:
This policy is supported only for company owned (Azure Active
Directory) organizations. Users creating organization using their
personal account (MSA or GitHub) have no restrictions.
https://devblogs.microsoft.com/devops/policy-support-to-restrict-creating-new-azure-devops-organizations/
We finally received a more concrete answer to this question from Premier Support. Sounds like this wasn't entirely clear internally either. Azure DevOps Services supports TRv1 which provides tenant restrictions from client to proxy, but does not support TRv2 tenant restrictions which provides server to server restrictions. TRv1 will prevent you from authenticating against an org outside your tenant directly but does nothing to prevent the background authentication that happens if your account is configured to be able to access a secondary tenant's org. The server to server connection strips off the header information necessary to restrict you from accessing the secondary tenant. While this feature may be on their radar there is no expectation or firm timeline for it's release at this time.
I am junior admin managing ADO 2020 on Prem . We have a developer who is able to create a work item in a board under a collection/project when logged in using ADO .
The developer is trying to automate work item creation using Power Automate . He is giving the correct information in Power Automate at the required fields. When trying to create a work item, he gets this error
Details: {"$id":"1","innerException":null,"message":"TF400813: The user '157adfsd-912f-4244-xxxx-b45fcasda\\firstname.lastname#domainname.com' is not authorized to access this resource.","typeName":"Microsoft.TeamFoundation.Framework.Server.UnauthorizedRequestException, Microsoft.TeamFoundation.Framework.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=acdb03fxxxxxxsdfdsdse","typeKey":"UnauthorizedRequestException","errorCode":0,"eventId":3000}
Question : From ADO 2020 side, is there any kind of permission I need to provide to the developer ? I am not 100 % sure why we get this error as the developer is manually able to create a work item.
To my understanding, Power Automate connects to Azure DevOps Services (that is, the cloud-hosted version of Azure DevOps) via OAuth, and when you are creating Power Automate flow for Azure DevOps, the tool tip when selecting an organization tells you to make sure that the Third Party application access via OAuth is enabled.
I don't think that the OAuth 2.0 authentication (https://learn.microsoft.com/en-us/azure/devops/integrate/get-started/authentication/oauth?view=azure-devops) is available for the on-premises version, so you might be out of luck there.
There is an answer to similar question in Power Automate-forum suggesting that the integration might be possible via installing an on-prem data gateway, but wouldn't really know if it's feasible.
https://powerusers.microsoft.com/t5/Connecting-To-Data/Power-Automate-with-Azure-Devops-Server-On-Premise/td-p/658618
I am creating a logic app that will trigger when a form request is submitted.
The MS Form connector requires me to sign in. This is acceptable during development, but we have a lot of logic apps and so use DevOps to automate deployment.
With the current connector, after deployment we still have to:
manually open the logic app in the portal.
connect using authorized credentials.
save the logic app.
This manual process completely defeats the point of using DevOps with Logic Apps.
Its a similar issue when using the Outlook connector.
Is there a way to supply server principal credentials to these connectors, so that they are correct at deployment time and require no manual intervention?
It seems that it's not supported to login on MS Forms connector with service principal. Connectors that can use service principal authentication will have "Connect with Service Principal" option, like Azure Data explorer. You can give your voice on this feedback to promote this feature.
API Connections with OAuth authentication, like Office 365 and Microsoft Team connectors etc, require manual consent. Unfortunately, at this point in time, authentication for those cannot be fully automated.
Here is a ticket you can refer to.
I am trying to setup Just in Time Access in Azure, so I have an account with subscription where I've enabled Security Center Standard edition (required for JIT). I've created there a Resource Group and a VM.
Now I took another account (let's call it a2#foo.com) and I've given it Reader privileges on the mentioned Resource Group and Contributor on VM and its Network Security Group.
After logging to the portal, a2#foo.com doesn't have access to JIT, because Subscriptions it owns don't have Security Center Standard enabled - these are separate subscriptions than the one mentioned earlier (so it's not possible to request JIT through the portal).
When I use PowerShell, I am able to select subscription where VM is deployed (Select-AzureRmSubscription), I am able to see that there is a JIT policy used there (Get-ASCJITAccessPolicy), but when I run Invoke-ASCJITAccess I get an error:
Invoke-ASCJITAccess : JIT VM Access requires a Standard tier subscription. For more info please visit aka.ms/asc-jit
Am I missing something or Just In Time Access works only on subscriptions you own?
Setting Contributor role for user a2#foo.com on the Resource Group solved the problem and this user is able to request JIT Access through PowerShell (not through portal).