Specific audit logs are not being generated.

[kohei-matsumura]

I changed the administrative permissions for a specific service principal in the account management screen.

I expected an audit log to be generated with service_name = accountns and action_name = changeServicePrincipalAcls, as described in the audit log reference, but it wasn't generated.

What kind of operation would generate an audit log with service_name = accountns and action_name = changeServicePrincipalAcls?

[Ashwin_DSA]

Hi @kohei-matsumura,

An audit log entry with service_name = accounts and action_name = changeServicePrincipalAcls is generated only when you change the workspace-level ACLs of a service principal... as in... when you use the workspace permissions API/UI to grant or revoke "Service principal user/manager" on that service principal at the workspace level.

The account console "Permissions" tab you used is backed by the Account Access Control API, which emits service_name = accountsAccessControl, action_name = updateRuleSet, not changeServicePrincipalAcls.

You may also find this useful.

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.

[kohei-matsumura]

Thank you for your reply. I understand that my criteria were incorrect.
I want to check if there have been any operations that changed the user or group that can manage the service principal. Is it correct to search using the conditions you suggested, `service_name = accountsAccessControl, action_name = updateRuleSet`?
Also, what other operations would be included in a search using these conditions?

[Ashwin_DSA · Accepted solution]

Hi @kohei-matsumura,

Yes.. if you want to find changes to account-console roles on a service principal (for example, who has roles/servicePrincipal.manager or roles/servicePrincipal.user), then service_name = 'accountsAccessControl' and action_name = 'updateRuleSet' is the right audit event family to search. The account-console permissions flow for service principals is handled by the Accounts Access Control API, and grant/revoke is done by updating the rule set for that service principal resource.

But those two predicates alone are too broad if your goal is a specific service principal. They will return all rule-set updates made through the Account Access Control API, not just service-principal-manager changes.

What else that search can include:

• updates to the account rule set: accounts/<ACCOUNT_ID>/ruleSets/default
• updates to a group rule set: accounts/<ACCOUNT_ID>/groups/<GROUP_ID>/ruleSets/default
• updates to a service principal rule set: accounts/<ACCOUNT_ID>/servicePrincipals/<SP_ID>/ruleSets/default
• updates to a tag policy rule set: accounts/<ACCOUNT_ID>/tagPolicies/<TAG_POLICY_ID>/ruleSets/default

So for your use case, the better filter is:

• service_name = 'accountsAccessControl'
• action_name = 'updateRuleSet'
• request_params['account_id'] = '<account-id>'
• get_json_object(request_params['name'], '$.name') = 'accounts/<account-id>/servicePrincipals/<sp-id>/ruleSets/default'

That narrows the results to updates to that service principal’s rule set specifically. Also note... updateRuleSet is a full replacement of the rule set, not a single "grant one user" delta event. One audit record can therefore represent multiple additions/removals/changes at once, depending on the final contents of request_params['rule_set'].

If you want to specifically inspect who can manage the SP, look inside the rule set for roles/servicePrincipal.manager. If you also care about who can use it, look for roles/servicePrincipal.user as well.

Some links if you find them useful.. 

https://docs.databricks.com/aws/en/dev-tools/cli/reference/account-access-control-commands

https://docs.databricks.com/aws/en/security/auth/access-control/service-principal-acl

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.

[kohei-matsumura]

Thank you very much!

I understand