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).
Related
I wish to grant users in a given AD group access to the Development Tools > Console function of the Production environment. I believe this is Kudu permission granted by assigning the Microsoft.Web/sites/publish/Action.
Is this possible without granting a member of the group the ability to publish web sites?
It is not possible to granting a member of the group the ability to publish web sites.
From the microsoft document it stated clear that you required microsoft.web/sites/publish/action resource provider operation.
Ones with Kudu access are ones owning the site - regardless if
read-only or not. To expand, they can deploy any codes (good or
malicious) to and able to read any secret settings of the site (eg.
KeyVault, SQL and Storage credentials, Private Certificates, etc.).
Hence for Azure, only those with Contributor / Owner access (to be
exact, with microsoft.web/sites/publish/action or, for slot,
microsoft.web/sites/slots/publish/action) can access to Kudu (SCM).
Refer this document for more information.
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.
So I am trying to build a Machine Learning pipeline on Azure DevOps. I followed this tutorial: https://www.azuredevopslabs.com/labs/vstsextend/aml/#author-praneet-singh-solanki
However, in Exercise 1- Step 3: Create or get workspace, I'm facing an error while authorising my Azure Subscription.
"Error: Insufficient privileges to complete the operation. Ensure that the user has permissions to create an Azure Active Directory Application."
Here is a snapshot of the problem. Also, my subscription is free tier as of now. Could that be a reason?
My subscription is free tier as of now. Could that be a reason?
No, you don't need worry about this. For free credit, we offered $200 free quota, and also the use will not be limited(just limit use depth only).
"Error: Insufficient privileges to complete the operation. Ensure that
the user has permissions to create an Azure Active Directory
Application."
This issue should caused by your incorrect role setting. Even you are owner of AAD or application, if you did not assign the role of Application administrator, you still will receive the error of permission not enough.
Please assign the role of your AD application to a Administrator permission. Go Azure Portal -> Azure Active directory-> Users, and then search your account which you will used in Azure Devops pipeline, and then follow the below setting to assign the role.
Then back to Azure Devops, refresh the Azure Subscription and Authorized again.
We currently have one DevOps repository, with a functional CI/CD pipeline. We have another website hosted on a different instance (and different region) on Azure. We are trying to use our existing repo to deploy to the other Azure instance, but it is giving is the following message:
Failed to query service connection API: 'https://management.azure.com/subscriptions/c50b0601-a951-446c-b637-afa8d6bb1a1d?api-version=2016-06-01'. Status Code: 'Forbidden', Response from server: '{"error":{"code":"AuthorizationFailed","message":"The client '2317de35-b2c2-4e32-a922-e0d076a429f5' with object id '2317de35-b2c2-4e32-a922-e0d076a429f5' does not have authorization to perform action 'Microsoft.Resources/subscriptions/read' over scope '/subscriptions/c50b0601-a951-446c-b637-afa8d6bb1a1d'."}}'
I have tried all of the recommended trouble-shooting, making sure that the user is in a Global Administrator role and what-not, but still not luck. The secondary Azure subscription that we are hoping to push our builds to is a trial account. I'm not sure if it being a trial account matters.
I came across the same error. It turns out that, as the error message states, the service principal didn't have Read permission over the subscription. So the solution was to go to Azure Portal, select the subscription, select IAM and assign the role Reader to my service principal. Full explanation on here:
https://clydedz.medium.com/connecting-azure-devops-with-azure-46a908e3048f
I have the same problem. There are one repository and two instances of the application on the Azure portal. For the first instance, the subscription Pay-As-You-Go is used, and there were no problems for it when creating the service connection and CI/CD settings. For the second instance, a free subscription is used and when trying to create a new service connection (Azure Resource Manager) I get the same error.
I tried to do it with the permissions of Owner and Contributor
UPD: I was helped by the re-creation of the application in the azure portal
https://learn.microsoft.com/en-ca/azure/active-directory/develop/howto-create-service-principal-portal
Another option would be to save without verification if the Service Principle will not require permissions at the Subscription level. Like for example providing access to a Keyvault.
Check if the service connection for the second instance is correctly added in project settings:
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.