In the docs they give an example of how to connect to a hub by using a connection string that contains a Shared Access Signature. So far in my app, I've been able to avoid storing secrets myself by just using managed identities. Is there a way to connect to a Notification Hub with a managed identity instead of a secret? I'd rather not do my own secret management.
Referring to list of supported Azure services that support managed identities for Azure resources it seems not available for it.
You may share your feedback by creating a Feedback item and upvote it. The product group monitors this site for feedback. This is the best way to ensure you are heard and you may receive a response depending on how much they information they can currently share.
Authorization Rules (a.k.a. Access Policies) are associated with a hub and can be accessed using Azure Resource Manager calls, which I believe supports managed identity. I've thought about this but haven't tried it myself. So please report back if it works for you.
Related
I created a Private Link connection between an Azure VM and a CosmosDB MongoDB Account.
In order to clear out the need for token authentication and taking into account the best practices, I assigned a custom role to the Virtual Machine which has permissions to read and write to CosmosDB.
Now I am trying to connect the VM to CosmosDB using Python (pymongo) without any type of authentication on the uri string. Nevertheless, I am having auth errors and I cannot seem to find any relevant example or information regarding this matter.
Is there any way to achieve this? If not, what are my alternatives? Must I use tokens even with a private link?
#Anupam Chand Thank you for your response in the comment section.
Yes, We Can avoid tokens by creating a service principal for your VM and then assign the appropriate RBAC to the service principal. At present .NET , Java and JavaScript SDKs are currently supported. Python SDK not yet available.
I came across a new release from the Azure about identity security as mentioned in the below docs.
https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/concept-fundamentals-continuous-access-evaluation#example-flows
I would like to evaluate and integrate with my application.
Looking for more informations about the process. Any pointers/links/docs would be really appreciable.
Continuous Access Evaluation is a new security feature that enables near real-time enforcement of policies on relying parties consuming Azure AD Access Tokens when events happen in Azure AD (such as user account deletion). Rolling this feature out first for Teams and Outlook clients. For more details, please refer this blog and documentation.
Does the Key Vault offer any benefit (security or otherwise) now that an app service can use Managed Identity to authenticate with other Azure resources? (E.g. azure storage and sql)
Is there any reason to use Managed Identity to access Key Vault and get a key for Storage, for example, now that an app service can directly use Managed Identity to talk to Storage?
You should always use Managed Service Identity where available, however they are not ubiquitous across all Azure. The list of supported services is maintained here. Keep in mind that the calling service needs to support authenticating with it's Managed Service Identity and the called service needs to be able to authenticate and authorise using Azure Active Directory.
When you have a service that does not directly support AD authentication (e.g. CosmosDB), then you still need to store and manage keys and KeyVault is still the right place to do this. This also applies to some 3rd party services like Salesforce, AWS, GCP, etc where "federation" may not be in place. You may also have additional sensitive config that you do not want to store in plain text.
Keep in mind that function appsettings can now directly reference KeyVault, saving the overhead of writing code and config to manage this yourself. See this link.
I would also say, that usage of managed identity should be preferred whenever possible. The major benefit I see is getting rid of credentials you have to manage. You outsource the authentication challenge to Microsoft here, and I would say it works very well.
One less credentials you need to protect, refresh, revoke etc.
I also believe that this goes well in the spirit of Infrastructure as a code, where you define you concern yourself with authorisation and leave secure authentication on the provider.
An instance profile is a container for an IAM role that you can use to pass role information to an EC2 instance when the instance starts.
http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html
A mechanism very similar to AWS instance profiles is Managed Service Identity (MSI) for Azure, which was announced in September 2017, though at the time of this writing, it is still in preview. I didn't try it out yet, but it does work the same way as instance profiles on AWS do, by automatically authenticating the VM to a meta-data service and allowing you to query for additional credentials without having to hardcode it into your code or image.
Azure also supports IAM.
Microsoft Azure identity and access management solutions help IT protect access to applications and
resources across the corporate data center and into the cloud. This enables additional levels of validation,
such as multifactor authentication and conditional access policies. Monitoring suspicious activity through
advanced security reporting, auditing and alerting helps mitigate potential security issues.
More detailed information please refer to this link.
Update:
You do have the ability to create Signed Access Signatures for all three Windows Azure Storage services (BLOBs, Queues and Tables) as well as for Windows Azure Service Bus Brokered Messages (Queues, Topics & Subscriptions). I have a similar question with you, maybe you could check.
I found Azure is not support instance profile like aws.
If bind a role to instance on aws, aws system will generate a temporary api access token and write to metadata server.
Aws sdk will auto fetch access token from metadata server, so a service that uses aws sdk does not need to configure sdk's access token.
But Azure's IAM and SAS(shared access signature) and metadata server, is not support mechanism like above.
I'm looking to manage certain settings of Azure via Azure Powershell from C#. I need to manage subscriptions for many many customers programmatically.
I want to ensure that anytime I open a PowerShell session to deal with particular customer's subscription, nothing of that session is left over in registry, certificate store, etc.
I have management certificates available to me as encrypted byte arrays. I can save them on the hard drive if needed.
I am also happy to call Powershell cmdlets not thru Powershell session but directly thru referencing objects in the .DLL
I would prefre to avoid the use of Management API directly in certain scenarios which is why I'd like to do so via Powershell
Is this possible? If so, how do I avoid using the certificate store? Ideally, I would prefer to just have a way to call into the cmdlet from C# without going thru Powershell session
You should start using Azure Active Directory credentials instead of X.509 certificates. Both the Azure Service Management (ASM) and Azure Resource Manager (ARM) mode of Azure PowerShell supports AAD while certificate authentication can only be used for ASM. Using AAD credentials means you NEVER need to use certificates of X.509 certificates, and be subject to the management difficulties they impose. You would need to be added as a co-admin to your clients subscriptions for ASM support (and the production portal) and provided an appropriate role for ARM support (and the preview portal). However, your customers could restrict your ARM and preview portal access with RBAC.
PowerShell has one cmdlet called clear-azureprofile ... And it clears all connections ... If you really want to be sure you better also clear the IE cookies and start a new PoSh session after both actions (so best to do it at the end of each session)... I agree with Neil btw: Stay clear from the certs... Aim for AAD
BUT ... Why don't you take a look at the management libraries(MAML? It's the basis for all you don't need to call REST and you can avoid PowerShell (that also uses MAML.) it's downloadable as nuget package
Find it here http://www.nuget.org/packages/Microsoft.WindowsAzure.Management.Libraries
And find info on it here http://azure.microsoft.com/en-us/updates/management-libraries-for-net-release-announcement/ and here http://www.bradygaster.com/post/getting-started-with-the-windows-azure-management-libraries
Hope this helps!
Only automated way is with a AAD account for the subscription. Be aware, the token expires in 12 hours. See June's fantastic blog post.
http://www.sapien.com/blog/2014/10/23/saving-passwords-for-add-azureaccount/