All the resources are in the same resource group. I have a service deployed in the service fabric cluster and I have a storage account. I also have registered an app in Azure Active Directory. How do I connect to the storage account? I want to use certificate/token based authentication and not connection strings.
I am pretty new to azure so I am confused about the basic stuffs.
You can use Managed Identities and grant access to it in your storage account.
https://learn.microsoft.com/en-us/azure/service-fabric/concepts-managed-identity
https://learn.microsoft.com/en-us/azure/storage/blobs/authorize-managed-identity
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.
We earlier used sas token to access the storage account.Now the requirment is to not to use it. Is it possible for an azure app to access the storage account if it has owner access. I tried using it . But getting this error.
message": "The specified resource does not exist
the url we are using is
`https://${tableService.storageAccountName}.table.core.windows.net/tablename
Simply pointing to a storage account, without any form of credentials, will not work for a private storage account or container.
There are a couple of options you have to provide credentials to connect to a storage account, like using the connection strings containing the access keys or using Managed Identities for Azure resources.
Managed identities provide an identity for applications to use when connecting to resources that support Azure Active Directory (Azure AD) authentication. Applications may use the managed identity to obtain Azure AD tokens.
Here are some of the benefits of using managed identities:
You don't need to manage credentials. Credentials aren’t even accessible to you.
You can use managed identities to authenticate to any resource that supports Azure AD authentication, including your own applications.
Managed identities can be used without any additional cost.
Because of these benefits and the ease of use I would suggest you Authorize access to blob data with managed identities for Azure resources.
Azure Blob Storage supports Azure Active Directory (Azure AD) authentication with managed identities for Azure resources. Managed identities for Azure resources can authorize access to blob data using Azure AD credentials from applications running in Azure virtual machines (VMs), function apps, virtual machine scale sets, and other services. By using managed identities for Azure resources together with Azure AD authentication, you can avoid storing credentials with your applications that run in the cloud.
Assign an RBAC role to a managed identity
When an Azure AD security principal attempts to access data in an Azure Storage account, that security principal must have permissions to the data resource. Whether the security principal is a managed identity in Azure or an Azure AD user account running code in the development environment, the security principal must be assigned an Azure role that grants access to data in Azure Storage.
we have a blob container with anonymous access (open to internet) and an appservice talking to it.
What are our options of ensuring that only the appservice can talk to this storage endpoint? vnet integration is our last option.
Thanks -nen
What are our options of ensuring that only the appservice can talk to
this storage endpoint?
One option would be to make use of Azure Role Based Access Control (RBAC) Data roles.
For this, first you would assign a managed identity to your App Service and then assign that identity appropriate Azure Storage RBAC data roles.
You would also need to block access to the storage account via access keys or shared access signature so that only your App Service can connect to your storage account using Azure AD authorization.
You can read more about it here: https://learn.microsoft.com/en-us/azure/storage/blobs/assign-azure-role-data-access?tabs=portal.
I have a App Service with a managed identity assigned to it to simplify connections to azure resources. I want to use DataProtection where the app stores the xml-keys in an Azure Storage Account(blob) to persist them between deploys.
Whenever I start the app I get a authentication error:
Microsoft.Azure.Storage.StorageException: This request is not authorized to perform this operation.
at Microsoft.Azure.Storage.Core.Executor.Executor.ExecuteAsync[T](RESTCommand`1 cmd, IRetryPolicy policy, OperationContext operationContext, CancellationToken token)
at Microsoft.Azure.Storage.Core.Executor.Executor.<>c__DisplayClass0_0`1.<ExecuteSync>b__0()
at Microsoft.Azure.Storage.Core.Util.CommonUtility.RunWithoutSynchronizationContext[T](Func`1 actionToRun)
I have assigned several different RBAC roles to the App Service without any succes, including:
Storage Data Owner
Storage Data Contributor
Storage Data Reader
Owner
The Storage Account is connected to a VNET and not open to the internet. THe App service is not connected to the same VNET.
I have then tried to whitelist the App services many outgoing IP-adresses in the Storage Accounts Network-section, which states "Add IP ranges to allow access from the internet or your on-premises networks."
Also have "Allow Azure services on the trusted services list to access this storage account" activated.
Any ideas whats missing? This is happening only when in the app service, from my debug-localhost I can connect, so seems related to azure networking somehow.
According to the description in your post, I can be pretty sure that your identity configuration in the portal is correct, and your code is also completely correct.
The only problem is that your app services cannot access vnet. The simple description is that the azure storage account is connected to the vnet, which is equivalent to being isolated by the vnet protection. The app service needs to access the storage account, and it must first connect to the vnet.
By default when creating an AKS cluster a service principal is being created for that cluster.
Then that Service Principal can be set on the level of some other Azure Resource (VM?) in order for them to be able to establish a network connection and for them to be able to communicate (except of of course general network settings)
I am really not sure and can not understand when this is required and when not. If for example I have db on VM level do I need to grant the AKS service principal access to the VM to be able to communicate with it through the network or not?
Can someone provide me some guidance for this, and not general documentation. When this is required to be used/set on the level of those other Azure resources and when it is not?
I cannot find proper explanation for this.
Thank you
Regarding your question about the DB, you do not need to give the service principal any access to that VM. Given that the Database runs outside of Kubernetes does not need to access that VM in any way. The database could even be in a different data center or hosted on another cloud provider entirely, applications running inside kubernetes will still be able to communicate with it as long as the traffic is allowed by firewalls etc.
I know you did not ask for generic documentation, but the documentation on Kubernetes Service Principals puts it well:
To interact with Azure APIs, an AKS cluster requires either an Azure
Active Directory (AD) service principal or a managed identity. A
service principal or managed identity is needed to dynamically create
and manage other Azure resources such as an Azure load balancer or
container registry (ACR).
In other words, the Service principal is the identity that the Kubernetes cluster authenticates with when it interacts with other Azure resources such as:
Azure container registry: The images that the containers are created from must come from somehwere. If you are storing your custom images in a private registry the cluster must be authorized to pull images from the registry. If the private registry is an Azure container registry the service principal must be authorized for those operations
Networking: Kubernetes must be able to dynamically configure routetables and to register external IP's for services in a loadbalancer. Again, the service principal is used as identity so it must be authorized
Storage: To access disk resources and mount them into pods
Azure Container instances: In case you are using the virtual kubelet to dynamically add compute resources to your cluster Kubernetes must be allow to manage containers on ACI.
To delegate access to other Azure resources you can use the azure cli to assign a role to a an assignee on a certain scope:
az role assignment create --assignee <appId> --scope <resourceScope> --role Contributor
Here is a detailed list of all cluster identity permissions in use