How to delete and "Account Level" Storage Credential ? (... I think)

[ThePussCat]

This is not a production platform, but I'd like to know the answer. I suspect I have done something stupid.

Using Account APIs, I created a Storage Credential.

Q1: I cannot see this in a workspace, and I do not know how to see it in the account console - how do I see it? (I can of course see it via Account API "get/list")

Using Workspace APIs, I cannot see this Storage Credential, which I think is to be expected.

Using Account APIs I cannot delete this credential as I seem not to have the permissions, although I am the OWNER

{

    "error_code": "PERMISSION_DENIED",

    "message": "User does not have MANAGE on Credential  ...***...

The Account APIs do not seem to have the ability to grant permissions. The Workspace APIs do, but cannot "see" this STORAGE CREDENTIAL.

Q2: How can I delete this STORAGE CREDENTIAL ?

Q3. What is the point of an Account-Level Storage Credential ?

It seems I cannot see it in a Workspace, so how would I use it?

Please tell me if I am doing something wrong!

[ThePussCat]

You know that "something stupid"...?   well it turns out I wasn't the OWNER after all, so I couldn't see it!

I made myself the owner and could see it in the Workspace (disabled), then I could make it accessible to workspaces of my choice and grant myself MANAGE permission, as I am an "admin".

But I'd still like an answer to Q3, if anyone knows? It seems a lot more logical to create a credential within a workspace...

Thanks!

[Ashwin_DSA]

Hi @ThePussCat - You didn’t do anything stupid. 

In Unity Catalog, a storage credential is always scoped to a metastore, not to a single workspace. It lives under the account/metastore, and can then be used from any workspace that is attached to that metastore, subject to bindings and privileges.

When you create it via the Account APIs, you’re basically creating:

• A Unity Catalog storage credential object in a specific metastore, backed by a cloud principal (IAM role/managed identity/service account).
• That object is global to that metastore, not tied to one workspace.

To see and use it in a workspace you must:

1. Make sure the workspace is attached to the same metastore where you created the credential.
2. In that workspace, go to Catalog --> External data --> Credentials (Catalog Explorer). Metastore admins (and the credential owner) can see all storage credentials for that metastore, even if they’re not bound to the current workspace. They’ll appear greyed‑out if not bound.
3. Optionally bind the storage credential to specific workspaces if you want to restrict which workspaces can use it (workspace bindings / storage credential isolation).
4. Use it to create **external locations** or as managed storage for catalogs/schemas/tables in notebooks/SQL:

CREATE EXTERNAL LOCATION my_loc
URL 's3://bucket/path'
WITH STORAGE CREDENTIAL my_cred;

Before Unity Catalog, everything was workspace centric, so per‑workspace credentials felt natural. UC shifts governance up to the metastore (account) level so you can manage one cloud credential and reuse it safely across multiple workspaces (dev/test/prod, different teams) instead of duplicating IAM roles and keys everywhere. You then control who can use it with grants and where it can be used with workspace bindings. It’s a bit less intuitive at first, but it greatly simplifies security, rotation, and auditing once you have more than a single workspace.

Hope this clarifies your question.

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

[ThePussCat]

HI Ashwin,

That absolutely makes sense to me, and I think what I should have expected.

However, and perhaps I have missed some reading here... the APIs to bind the storage credential to a workspace, and to grant privileges seem to me to be "workspace APIs" when I would expect there to be Account APIs for this stuff.... ?

For example:   using [PATCH] /api/2.1/unity-catalog/storage-credentials/{name} to set an isolation seems to me that this should be an Account API, and not something directed from a Workspace. That does not seem logical to me.

Obviously the caller has to have the correct permissions anyway, but I would have thought that Account APIs would create, Isolate, assign which workspaces have access, etc.

Am I missing something?

[Ashwin_DSA · Accepted solution]

Hi @ThePussCat,

You’re not missing anything. This is mostly about where UC is surfaced, not about who controls it.

Unity Catalog objects (including storage credentials and their workspace bindings) are metastore‑scoped, and the metastore is attached to workspaces, so Databricks exposes most UC management APIs via the workspace URL, even though they operate on shared, account‑level governance objects.

The key constraint is permissions, not the endpoint. Only account/metastore admins (or object owners, depending on the action) can call those APIs successfully, regardless of which workspace URL they hit.

Think of the workspace UC API endpoints as a "window into the metastore" rather than workspace‑local configuration. The control plane still enforces that only properly privileged account‑level identities can create, bind, or grant on those storage credentials.

Hope that clarifies. 

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