I'm using Octopus Deploy to deploy an Azure WebApp, using Service Principal as the authentication mechanism. Following online instructions, I was able to obtain all the id's and a key, and I created permissions in AAD for the app with a Reader role.
Octopus can successfully retrieve a list of webapps from Azure for the account, but when I deploy I get the following:
System.AggregateException: One or more errors occurred. --->
System.Exception: Retrieving publishing credentials failed with HTTP
status 403 - Forbidden
I'm guessing that the Reader role is not authorized for deployments - which would be the most appropriate role? Or is there something else I need to do?
Your Service Principal will need the Contributor role in order to deploy on Azure.
If you take a look at the example PowerShell script we provide in our Azure Service Principal Account guide, you'll see that we assign "Contributor" for the role definition argument.
ie.
New-AzureRmRoleAssignment -RoleDefinitionName Contributor -ServicePrincipalName $azureAdApplication.ApplicationId
Hope this helps.
If you only use the Service Principal to deploy web app, you could give it Website Contributor role.
Website Contributor Can manage websites, but not the web plans to
which they are connected
Actions that Website Contributor could access please refer to this link.
If you want the service principal to create app service plan, you also need give it Web Plan Contributor role.
Owner and Contributor can manage everything, if you need to fine-tune permissions, I suggest you select Website Contributor role. More information please refer to this link:Built-in roles for Azure role-based access control.
Please refer to this link:Assign application to role.
Related
Stuff in Azure are secured with Service Accounts. In order for me to see stuff I need to download the Service Account certificate and then log in via the Azure CLI using the extracted certificate and the Service Account Application Id. So now I can see everything the Service Account can see, great. But it is a pain in the neck and slow. So my question: Can I use the same certificate and credentials to log into the Azure Portal website so I can browse around using the web browser instead?
Using a Service Principal for interactive logins to the Azure Portal is not possible - which is by design. In order to be able to see the same resources as the Service Principal through the Azure Portal, you would require a user account that holds the Azure RBAC Reader role against those resources that are in scope of the Service Principal role assignments.
As you mentioned performance being an issue with using the Service Principal login, you could try Azure Resource Graph queries. These are supported by Azure CLI, Azure PowerShell as well as all the major Azure SDK's. Obviously, this won't bring you the visual experience like the Azure Portal but might resolve the performance piece maybe.
However, requesting/creating a user account that has the corresponding RBAC roles assigned would be the only way to allow you to see the resources through the Azure Portal.
I have created an automated Service Principal from the service requests on Azure Devops with sufficient permissions. Now, when I am trying to create an artifact which is an ML model (registered) it is not auto populating the registered models and resulting in an error.
I am using a free trial Azure account and attempting to implement CI CD for ML. I turned my firewall off and attempted as well but still the issue persists.
It appears that the Service Principal is not assigned the role in the appropriate subscription.
You need to grant the service principal Azure subscription access permission:
Login Azure portal->All service->Subscriptions->click your subscription->Access control(IAM)->Add role assignment->assign the correct role to your service principal
Refer to Use the portal to create an Azure AD application and service principal that can access resources and Assign Azure roles using the Azure portal for details.
I am creating my first app function using powershell in the Azure portal, It's just to scale a SQLDB on I have tried to use this tutorial as a guide.
MSI example
I turned on MSI for the function and configured resources groups Giving the contributor role to the resource
When I run the function within the portal, I get the message doesn't have authorization to perform action. from this tutorial I believe this is all I had to do ? I have waited over a day to see if it's a timing issue, from the example I Have followed and this MS document managed identies for app service
I don't believe I need to add any secret key for this to work?
Function Error message
Setting the function MSI identity to on
Seeting the access control in
The service principal you are using doesn't have rights within that tenant.
Tenants have subscriptions and service principals belong to tenants. Azure resource manager also exposes role based authorization for a given principal, which would give it rights on Azure resources. It appears the service principal doesn't have rights to read from that subscription.
Go to portal and find your subscription, click on Access Control (IAM) and then click on Add role assignment with correspond service principal which you use to acquire token.
After you have given successful permission, refresh and try again.
Service principle can be created without role via az ad sp create-for-rbac --skip-assignment
Q1. What's the use of a service principal without a role?
Q2. Can a service principle exit without attaching to any scope/resource? If so what's the use of such independent service principle?
Q1. What's the use of a service principal without a role?
The parameter --skip-assignment skip assigning the service principal to the subscription. So to be precise, your question should be without an RBAC role, because there is another role named Administrator role, it will be mentioned below.
Some usages here for you to refer to, there are many usages mixed with the AD App, will not go into details here. If you want to learn about them, you can look into the Azure AD official doc.
1.The service principal can be assigned as an Administrator role in Azure AD, then it can do the things depend on the role permissions, e.g. create a user, delete a group. Via Azure AD powershell, Microsoft Graph API, Azure AD Graph API, or the AAD part of the Az powershell module.
2.The service principal can also calls the APIs and use the powershell above without Administrator role, but you need to give the application permission to it. The az ad sp create-for-rbac will create an AD App along with a service principal, in the AD App in the portal -> API permissions, you can add the permission and consent. Note, when we add permissions and consent in AD App, actually the permissions will be given to the service principal in your tenant, the service principal is an instance of the AD Application in a specific tenant.
Q2. Can a service principle exit without attaching to any scope/resource? If so what's the use of such independent service principle?
Yes, as mentioned above, it can do many things related to Azure AD, Graph API. Here is a doc about Application and service principal objects in Azure Active Directory, it will be really helpful for you to understand the service principal.
A1- you can use it to remove the need of secret keys in your apps. For example, rather than storing the Azure Storage access key, you can grant an identity (your app) to store / access data on Azure Storage.
A2-I think so, it will be a system-assigned managed identity which is a special kind of managed identity (service principal)
I am deploying a standard ASP.NET MVC application to an Azure App Service using a VSTS build and release definition. The VSTS instance and the target Azure subscription are on separate Azure accounts/subscriptions so we have create a Azure AD application and Service Principal account to authorize the deployment.
When adding the Service Principal account to the subscription, it wants us to assign a role.
What is the best and least privileged role that can be used to deploy the site?
When add Azure Resource Manager Service Endpoint, it mentions:
A new Azure Service Principal will be created and assigned with
"Contributor" role, having access to all the resources in the selected
subscription.
So, the Contributor role is better.
On the other hand, to configure Azure RM service endpoint, you must be a member of the Global Admin role in the directory. More information: Insufficient privileges to complete the operation.