Azure
Is there a feature to enable auditing of configuration key-value pairs
Hi i want to enable auditing for key-value pairs on addition updation or deletion of config key/value. Is there a feature/ solution to support this requirement. Do we have any best practice recommendations to achieve the same.
Auditing is enabled by default and we are currently working on exposing auditing logs to Azure Monitoring, where you can setup to export logs into several destinations (Azure Storage, Event Hub, Log Analytics Workspace). It will be done in the next couple weeks.
Once that is finished, you can query your logs in Azure Portal using Azure Data Explorer (Kusto) query language or hook up with Storage/Event Hub for other usages.
Hi, I see the audit logs for App configuration have two kind of operation getting logged i.e set-key value and other is list-config-sore. How can i get the UPN for set-keyvalue operation. Can we see this as a feature for Audit purpose?
@snehafar Yes, this is a feature that we can add. BTW, not all data plane requests(key value related) can have UPN. If the request is authenticated with connection string, only key id is audited. If it is AAD, UPN will be available for personal identity only instead of service principal.
@snehafar Yes, this is a feature that we can add. BTW, not all data plane requests(key value related) can have UPN. If the request is authenticated with connection string, only key id is audited. If it is AAD, UPN will be available for personal identity only instead of service principal. Thanks for the reply @shenmuxiaosen any ETA for thi? The problem that we are facing at present is we are unable to identify who has performed the modification on the app configuration "feature manager" when we take out the audit logs.
@shenmuxiaosen Also the data plane request operation we are referring here is for "set-keyvalue" operation Right? Since for "list-config-store" operation I can see the UPN.
@shenmuxiaosen Also the data plane request operation we are referring here is for "set-keyvalue" operation Right? Since for "list-config-store" operation I can see the UPN.
Yes. We are working on adding UPN for "set-keyvalue". Considering the holiday season, we are planning to roll it out by the end of this year. BTW, to know the caller, we can still use the appId, tenantId, and objectId to identify which identity is used for the "set-keyvalue" operation. If the request authenticated with connection string, then only secret name will be available.
@shenmuxiaosen Also the data plane request operation we are referring here is for "set-keyvalue" operation Right? Since for "list-config-store" operation I can see the UPN.
Yes. We are working on adding UPN for "set-keyvalue". Considering the holiday season, we are planning to roll it out by the end of this year. BTW, to know the caller, we can still use the appId, tenantId, and objectId to identify which identity is used for the "set-keyvalue" operation. If the request authenticated with connection string, then only secret name will be available.
Thanks @shenmuxiaosen . But w.r.t caller details the app id,objectid and tenant id comes only when list-configstore-keys operation is performed and also the caller identity type shown is upn and so can see the upn details as well. Problem is when set-key-value operation happens I dont see any object id,tenant id,app id rather get to see caller identity type as "KeyName" from which cannot figure out the user details. Also this caller identity is coming same for any user who goes and do some modification in app configuration.
@shenmuxiaosen Also the data plane request operation we are referring here is for "set-keyvalue" operation Right? Since for "list-config-store" operation I can see the UPN.
Yes. We are working on adding UPN for "set-keyvalue". Considering the holiday season, we are planning to roll it out by the end of this year. BTW, to know the caller, we can still use the appId, tenantId, and objectId to identify which identity is used for the "set-keyvalue" operation. If the request authenticated with connection string, then only secret name will be available.
Thanks @shenmuxiaosen . But w.r.t caller details the app id,objectid and tenant id comes only when list-configstore-keys operation is performed and also the caller identity type shown is upn and so can see the upn details as well. Problem is when set-key-value operation happens I dont see any object id,tenant id,app id rather get to see caller identity type as "KeyName" from which cannot figure out the user details. Also this caller identity is coming same for any user who goes and do some modification in app configuration.
This means requests authenticated with access keys (connection string) instead of using AAD. Anyone who has this key can use it to auth with server. There is no way to identify who is holding this key. For each App Configuration store, there are four access keys read-write vs read-only, primary vs secondary. The keyName in the audit log is the key identifier (Id) as in this screenshot.
However, for management plane requests, like "list-configstore-keys", requests are processed by Azure Resource Manager which can only be authenticated with AAD. So if you use your personal identity then UPN and appId/tenantId/objectId of the identity will be audited.
Yes. We are working on adding UPN for "set-keyvalue". Considering the holiday season, we are planning to roll it out by the end of this year.
@shenmuxiaosen is this done?
The UPN is part of the auditing logs if a key-value is created/modified/deleted by a user with AAD auth (not using the connection string).