Is it possible to prevent subscription keys being visible to APIM admins? I want them to only be visible to the developer in question via the developer portal.
I have admin access to an APIM instance. I have access to the subscription keys of all of the user accounts by toggling the Show/hide keys option for any particular record. I don't want this to be the case, I would like it to be a secret they generate for themselves that no one else can see.
Is this possible at all? If not is there a similar alternative?
Firstly, created the 2 users in Azure and given access to only APIM Resource as APIM Service Contributor.
Created the 2 Subscriptions in the APIM by logging to the APIM resource using both of the user's credentials in Azure and given owner access to opposite user.
Using these subscription keys, we can secure the APIs published to the APIM Resource where we can prevent the users to access our APIs data using those keys, so Admin consent is required to approve the subscription keys request for the users.
I believe, it is not possible to restrict the admins from visibility of Subscription keys in APIM.
Related
I work at an organization that uses Azure and I need to set up an ETL process that will pull data from an API. Based on my research, everywhere on the internet says I should use Azure Key Vault to store the credentials rather than hard code them into Data Factory. I created a "secret" within a key vault that I created and configured the settings to only grant access to my windows login. However, my Azure subscription is part of an enterprise/multi-tenant subscription and I had a colleague (who has never used Azure before) screen-share with me, and he was able to access the credentials in the key vault I created simply by changing the access settings to "public" (he is able to see them in plain text after modifying the Network/Security settings).
Is this the expected behavior? I can see the benefit of allowing other user to modify the setting for a Key Vault (if I leave the company for example), but I'm not sure if there is a way around this, because I would assume if my co-worker (who is not admin-level) can see these credentials, than the IT department and/or higher-ranking people would be able to access these credentials quite easily...
Pretty much everything I find online says I should store credentials in Azure Key Vault, but if my whole organization has the ability to access the secrets, doesn't that seem like a major security issue?
Access Policy settings - Application is an Azure Data Factory instance which I created, User is my login/account
Networking settings - Private endpoint option is selected, but currently no private endpoints are on the access list. Co-worker was able to change this to "All networks", ultimately granting him access to view secrets.
Your colleague is probably having Owner or Contibutor role on subscription level. So he can change Key Vault settings and grant access to himself. This behaviour is by design.
It is explained in Microsoft article about Key Vault security:
If a user has Contributor permissions to a key vault management plane, the user can grant themselves access to the data plane by setting a Key Vault access policy. You should tightly control who has Contributor role access to your key vaults. Ensure that only authorized persons can access and manage your key vaults, keys, secrets, and certificates.
I have created an AZURE CSP subscription for a customer. When I log in to the particular customer directory as a partner admin user (Customers -> Click the dropdown for a customer -> Microsoft Azure Management Portal link), I am able to see the subscription. But when I try to login as the admin of the customer domain/directory, I am not able to see it.
When I searched about it, I came across the link
https://learn.microsoft.com/en-us/partner-center/assign-azure-subscriptions
Is there any way to do the step Assign Azure subscriptions to your customers through API.
You could use Azure Rest API Role Assignments - Create or Role Assignments - Create By Id.
You can see that there is a Try It feature in the page but we cannot make it work with an CSP admin, because if we sign in with an CSP admin, the access token will be issued for the CSP admin's tenant rather than customer's tenant by default.
To call Azure rest API, you need an access token for Azure. Please refer to this document.
Here is my sample for your reference:
Get the access token for Azure service in Postman. Sign in with your CSP admin to generate the access token. Remember that you should put the customer's tenant id in Auth URL: https://login.microsoftonline.com/{custopmer's tenant id}/oauth2/v2.0/authorize and Access Token URL: https://login.microsoftonline.com/{custopmer's tenant id}/oauth2/v2.0/token
Use this access token to assign Azure subscription using Role Assignments - Create.
Here is a scenario. I have a SaaS product that needs to make api calls to customer's Azure cloud account. I understand a service principal can be created on the customer's AZ account, and if I have the credentials(app id, password, etc), I can make calls using that user/principal based on the permissions to that principal. One way is that customer creates it for my product, then comes to my product portal(web ui) and punches in this information which my SaaS product can then store securely in vault and use it.
Is there a better way to achieve the creation of the principal? For example via application manifest or something and then also be able to get a Event grid notification or something with the app/principal's creds to a webhook url endpoint?
Basically, I want this to be as automated as possible but cannot think of a way if it is even possible.
Normally if you are writing a multi-tenant application, you will set up your app registration as multi-tenant, and you will call the "common" endpoint for all users to log in.
when the admin from a different tenant logs into your application, if set up properly, a consent window will appear and when they consent, the Service principal will automatically be created in their tenant.
please see here: https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-convert-app-to-be-multi-tenant#understand-user-and-admin-consent
General Overview of what I am trying to achieve
I am trying to build an Azure AD Multitenant Web application which allows me to manage resources in customer subscriptions/tenants using the Azure Resource Manager (ARM) APIs. I am pretty new to Azure AD Multitenancy.
The Ideal control flow
1. A customer browses the Applications (ideal an admin of the customer tenant)
2. Will be granted with Azure AD authorize flow
3. Accepts everything and grants admin consent for the AD App in their tenant
4. Unclear: The AD App will be granted contributer access on a subscription or resource
5. My Web App will be able to use the AD App credentials to manage the customer resources using the ARM APIs
Problem
Steps 1-3, 5: Are clear and I know how to build that.
Step 4: I am not sure how to build that so that step happens automatically.
Solutions I have considered
The worst case would be the customer AD Admin must manually grant the AD App access to a subscription or resource using the Azure Portal.
One idea that came to my mind is that you require the user_impersonation permission on Azure Service Management API.
After the user logs in, you could list out the subscriptions available, allowing the user to select one.
Then list out the resource groups if needed.
Once the user confirms a selection, your app could add itself as a Contributor on the targeted resource through the Management API, on behalf of the currently signed-in user.
To do this, you will need the object id of the service principal for your app created in the target tenant.
You can get it by acquiring an app-only token for e.g. the Azure Management API from that tenant's token endpoint after the user has logged in.
The token will contain an oid claim, which is the object id for the service principal.
Of course the user who signs in would have to have the ability to modify access to the target resource.
I would say the downside of this approach is that the organization must trust your app to only do the thing it claims to do.
The approach where they grant the access manually allows them to be in control fully.
I am trying to find security best practice on App permissions in the context of azure resource management.
Currently, there is only one permission listed for management.azure.com and it is
management.azure.com/user_impersonation (preview). This delegated user impersonation can be a serious problem and it can led to account takeover by malicious app.
Think about a scenario where a user with global administrator role consent and authorize an access token to the app. App can use the token and do whatever it wants with the azure tenant.
Another scenario where a privileged user assigned contributor role to multiple subscriptions. Token authorized by this user can be misused by app to modify resources in any of the subscriptions.
Unlike graph (graph.microsoft.com) api where you can handpick the permission (user.read), resource management api has only one option - user_impersonation!
You may argue why would a privileged user authorize the action but people make mistakes. Our job is to stop or minimize such risk by design. So, what's the best way to allow app to manage resources in azure and minimize the security risk?
Thanks to #juunas for outline and tips. Thanks to #Gaurav for attempting to address my question. I was able to modify azure resources on a subscription without having to grant user_impersonation on management.azure.com api. Here are the steps-
1) Register an app (TestPermissions in my case)
2) Add API Permissions (optional). You don't need to add management.azure.com.
3) Go the Azure resource (subscription, resource group or management group level based on your requirement) and add IAM/RBAC role to the registered app. I assigned Contributor role to TestPermissions app at the subscription level.
4) Request a oauth2 access token following client credential grant flow. You can provide client_id and client_secret in the body of the POST request or you can provide it as Authorization Basic base64 encoded header (that's what I did). Save the access token for future use (until it expires).
Note: I could not add multiple audience (scope) at the same time. If you would like to get a token for graph api, you can request a separate token by changing the scope to http://graph.microsoft.com/.default
5) Use the access token captured in the previous step to interact with azure resource manager. You will need to add the jwt bearer token in the Authorization header (not shown here) on every request to https://management.azure.com. In this example, I am creating a new resource group named TestCreateRG003 to one of my Pay-as-you-go subscription.
6) Let's validate/verify that the resource is created or updated in Azure. Bingo, there they are! App can read/modify (based on RBAC) azure resources w/o having to grant impersonation permission.
It is true that by granting that permission you are allowing the app to act as you, with all the permissions that brings.
The main way I've seen used when limitations are desired is that you:
Register an app in your Azure AD
Grant the service principal the necessary roles (e.g. Reader on specific resources)
Set the tenant id, client id, client secret etc. in the app
This of course requires that the app itself supports this approach.
If it only allows usage through impersonation, then you'll need to either trust or not use it.
Let me see if I can answer this question.
When a user requests a token for management.azure.com, all is done at that time is that the user has permission to execute Azure ARM API. That doesn't mean that they can do everything that's possible with Azure ARM API.
The things that they can do is controlled by Azure Role Based Access Control (RBAC). So if a user is in the Reader role, the token got on behalf of the user can only read information about resources in their Azure Subscription. They will not be allowed to create, update or delete resources in their Azure Subscription.
What you will need to do is grant users appropriate RBAC role to minimize the risks of misuse.