My WebJobs app uses an Azure Storage Queue Trigger. It runs smoothly when the connection string to the storage account the queue app listens to is set-up in the configuration; i.e. appsettings.json.
{ "AzureWebJobsStorage": "connString" }
However, I do not want to expose any secrets in the configuration and more importantly, I'd like to avoid access keys altogether, relying on Azure AD and role-based access control (RBAC) instead.
For this, I have assigned the service principal running the application the Queue Data Contributor Role and switched in the connectivity type of the queue from Access key to Azure AD in the portal.
My intent was to use the Azure Identity SDK and new-up an instance of DefaultAzureCredential and use that to connect my app to the queue.
But as far as I can see, the Webjobs SDK expects to connect using acres key, i.e. a connection string. When using the standalone storage queue client, this is straightforward, since I can create the queue client using above-mentioned Identity SDK. However in WebJobs it seems I cannot override the means of connecting to that queue.
How can I access that queue via Azure AD and RBAC? Any help on this is greatly appreciated!
Currently, the bindings used with the WebJobs SDK do not support using the identity SDK.
Instead, you could store the connection string in KeyVault and use the KeyVault References feature which relies on Managed Identity to fetch the secret from KeyVault at runtime.
Directly using the respective client SDK would be the way to go otherwise.
Related
I want to stop using mounts and tighten up security and reduce cost using job clusters.
I want to use passthrough credentials. I've created a notebook that reads avro and converts it to parquet. It works when I run the notebook; however, job fails when it runs as service principal or my account. Service principal is blob contributor. I'm not able to run working notebook as a job.
I've tried using job cluster and existing high concurrency cluster and I get error below in both cases:
Error message:
Py4JJavaError: An error occurred while calling o498.load.
: com.databricks.backend.daemon.data.client.adl.AzureCredentialNotFoundException: Could not find ADLS Gen2 Token
AAD credentials passthrough doesn't work for jobs, especially for jobs owned by service principals. AAD passthrough relies on capturing the user's AAD token and forwarding it to ADLS...
But if you're already using the service principal, why not configure the job for direct access to ADLS as it's described in the documentation? You just need to set Spark conf properties in the job cluster (replace values in <> with actual values):
fs.azure.account.auth.type OAuth
fs.azure.account.oauth.provider.type org.apache.hadoop.fs.azurebfs.oauth2.ClientCredsTokenProvider
fs.azure.account.oauth2.client.endpoint https://login.microsoftonline.com/<azure-tenant-id>/oauth2/token
fs.azure.account.oauth2.client.id <sp-client-id>
fs.azure.account.oauth2.client.secret {{secrets/<secret-scope>/<secret-key>}}
I have a Azure Logic App, which is connecting to the SQL Server Database. Currently I am saving the connection string in configurations section of the logic app.
I am planning to use the azure keyvault and get the connection string from there.
I have gone through the online articles which tells about the keyvault connector. but I am not looking for that.
I want to use the Keyvault secret for my sql server connections in the Azure Logic App.
I have also tried with the SQL GetRows as you can see below but I don't see any connection string textbox, where I can use the GetSecret Action Result
As #Skin mentioned You can use Azure Key Vault's Get Secret action in your case. For this search for Azure Key Vault Connector and select Get secret action.
Now you need to establish a connection to your Key Vault by providing your Vault name and Tenant.
Then select the secret that you want to retrieve
After you run the logic app you can see the value that got stored in your key vault.
In Vault:-
The connection strings are saved as application settings of the Logic App.
Change connection string in configuration
There you can edit the app setting related to your connection string (sql_connectionString in my case) with #Microsoft.KeyVault(SecretUri=<keyvault name>.vault.azure.net/secrets/<name of your secret>) or optionally #Microsoft.KeyVault(SecretUri=<keyvault name>.vault.azure.net/secrets/<name of your secret>/<version>).
Once you save your application settings, you will see a green check and Key vault Reference in the source column of your application setting.
Key vault Reference
We are using a third-party IT provider that handles our network administration and domain accounts, but as part of moving to a different office and setting up new infrastructure, we are considering dropping that and using Azure Active Directory only.
Researching the topic online seems to indicate that Azure AD is not a complete replacement for on-premises Active Directory, as things like local resource access and group policies outside of Azure would be missing. However, we are moving towards using Azure for most things (file storage, etc), so that should be fine if we still have that functionality there.
Before finalizing the decision to go in that direction, we just need to be certain of a few things:
1) Is there a way to create a new account in Azure AD so that it can be used to login from any machine in the office, without having to create it locally first and then connect the two?
2) Is there a way to sync user data, such as user/desktop files, across any devices the account is used to log into?
3) Is it possible to have an office printer configured in Azure so that it can be used with an Azure AD login, completely independent on any on-premises setup (i.e, not Hybrid Cloud Print, which seems to require an on-premises network/AD to be joined with Azure AD)?
The goal is to be able to log in and work from any internet-connected device, whether in the office or at home, without needing to use a VPN and/or remote desktop, and forego on-premises AD administration.
This is possible as long as the device is joined to Azure AD. Once the device is joined to Azure AD, then newly created cloud-only users can also login to the devices.
Ref: https://learn.microsoft.com/en-us/azure/active-directory/devices/concept-azure-ad-join
Enterprise state roaming should help in this aspect. It might not cover everything you are looking for but the important app-specific data and user settings are synced.
Ref: https://learn.microsoft.com/en-us/azure/active-directory/devices/enterprise-state-roaming-overview
There is no direct solution from Microsoft for pure cloud scenarios. There are few 3rd party services offered for this.
Ref: https://appsource.microsoft.com/en-us/product/azure/printix.64182edf-4951-40d5-91c8-733e1c896b70
Hope this helps.
Can someone help me understand the difference between the Service Principal created when I create an App Registration in AAD and the Managed Identity that gets created when I enable "System Assigned" on the Identity blade of an App Service?
We have an App Service that we are developing that we have created an App Registration for and we have also enabled the System Assigned identity. When we go into Enterprise Applications under AAD and search for our app, it comes up with 2 entries. One for the Managed Identity and one for the Service Principal created as part of the App Registration. We are trying to understand which one we would use to give the app permissions to write to an Azure SQL DB.
Managed Identities are essentially service principals wrapped with Microsoft logic to make accessing resources simpler. Although, sometimes adding more layers may complicate things, the idea is to make it easier, simpler, and less consumer interactive.
For your scenario, you'll want to think about what you would like to do. Would you like to have more control and implement your own logic with an Azure SQL DB protected by AAD, or try utilizing Microsoft's Managed Identity to protect/access the Azure SQL DB resource. (Ideally the Managed Identity path should be less work)
The tutorial for using Managed Identities to access an azure SQL db from an app service can be found here :
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-connect-msi
The docs for protecting an Azure SQL DB using Azure AD can be found here :
https://learn.microsoft.com/en-us/azure/sql-database/sql-database-aad-authentication
Furthermore Managed Identities are explained in the official Microsoft documentation here :
https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview
It's important to note that there are two kinds of Managed Identities.
From the documentation:
A system-assigned managed identity is enabled directly on an Azure
service instance. When the identity is enabled, Azure creates an
identity for the instance in the Azure AD tenant that's trusted by the
subscription of the instance. After the identity is created, the
credentials are provisioned onto the instance. The lifecycle of a
system-assigned identity is directly tied to the Azure service
instance that it's enabled on. If the instance is deleted, Azure
automatically cleans up the credentials and the identity in Azure AD.
A user-assigned managed identity is created as a standalone Azure
resource. Through a create process, Azure creates an identity in the
Azure AD tenant that's trusted by the subscription in use. After the
identity is created, the identity can be assigned to one or more Azure
service instances. The lifecycle of a user-assigned identity is
managed separately from the lifecycle of the Azure service instances
to which it's assigned.
The picture from the official docs also gives a good example of a VM using MSI(Managed Service Identity).
This is Provided below:
In addition to that, the App Service Managed Identity documentation can be found here :
https://learn.microsoft.com/en-us/azure/app-service/overview-managed-identity
I would like to elaborate a little further as the topic around service principals and app registrations in Azure can be confusing.
As you noticed, a service principal will get created in your AAD tenant when you turn on system-assigned managed identity for a resource in Azure. This service principal is tied to the lifecycle of your resource or in other words: If you delete your App Service, Azure will delete the service principal for you [2].
Beside service principals, there are other object types that live inside a tenant: User principals and application objects. As the name suggests, user principals identify a user while a service principal can be used to either identify a resource in Azure or an application object. To both types of principals you can assign roles, as you mentioned you can create a new user in your database and use the system-assigned identity (Service Principal 1 in the image below) to let Azure SQL know that your App Service has permissions to access the database [3]. This is marked in red in the image.
When you create an app registration, two objects are created: An application object and a service principal in your tenant (this is "Service Principal 2") [4]. You could now use this service principal as well to give it permissions to access the database (marked in orange in the image) but this service principal is not tied to your Azure App Service and doesn't represent it. In other words, if you want to use Service Principal 2 in your App Service, beside creating a user for this service principal in your database you'd additionally also need to get an access token for this service principal whenever you create a new SQL connection to the database in your application. It's possible but a bit more inconvenient and the beauty of using system-assigned identities is that your App Service knows about its service principal already and you don't have to manage it on your own (e.g., delete it when your App Service gets deleted).
Long story short: Use the system-assigned managed identity in your use case.
[2] https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview#managed-identity-types
[3] https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-connect-msi#grant-permissions-to-managed-identity
[4] https://learn.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals
You can only use the managed identity that you have enabled in your App Service for authentication to AAD which eventually allows you to access your Azure SQL instance based on roles/permissions. I'd tried using the service principal/Enterprise Application created as part of App Registration process for authentication and it didn't work.
The way I see it is that the App Service is what runs/hosts your application and only this managed identity/SP is available to your running application for authentication to AAD.
The Service principal/Enterprise Application is being used internally for some other purpose and, it is not available to our application for authentication to AAD.
Just a wee note. App Registration may live without Service Principal. App Registration may represent an application that is consumed, not necessarily the consumer.
Managed Identity is solely a client-based identity.
E.g. Your App Service is acting as a client, when accessing Azure SQL. In this case you don't need an app registration and its service principal at all. You will only need a Managed Identity (which is a Service Principal).
When your App Service (A) is opposed to access another App Service (B) then again your App Service (A) does not need an app registration. But App Service B needs to have an app registration.
Imo when you want to use the credential-less approach in Azure, an app registration is acting as the server part and a Managed Identity (system - or user-assigned) is considered to be the client part.
We have an instance of SSRS running on 'Local System' service account. I have added the SMTP settings to the Configuration Manager. I now want to change the service account to use an authenticated Windows AD account to I can access the Exchange server and utilise subscriptions.
I am using 2008, other than a need to restart IIS/RS I want to check about the symmetric keys that are used for accessing the report server database that have been encrypted with the local machine.
I want to check the steps and caveats of changing the service account in configuration manager from Local System to MyDomain\My.User.
This page mentions about having to backup encryption keys first, then removing the reference to it after stopping IIS. Updating the service account and creating a new key before starting IIS.
So I need to do/worry about this or will the tool just handle this?
I suspect the tool 'should' manage all this for me but we know what assumptions are.
You need to use the Reporting Services Configuration tool to make changes to the service account being used. If you use this tool then it will automatically take care of permissions changes and modifying encryption keys. More details are available on MSDN.
The issue described on the website you linked to probably occurred because the service account was changed using the Services management tool in Windows, rather than the Reporting Services Configuration tool, and therefore the encryption key was not automatically updated.
Regardless of the above you should always back up the encryption keys for the report server and store them elsewhere.