<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Heads-up: collaborator with READ on Secret Scope could delete a key from my shared notebook in Data Governance</title>
    <link>https://community.databricks.com/t5/data-governance/heads-up-collaborator-with-read-on-secret-scope-could-delete-a/m-p/135567#M2641</link>
    <description>&lt;P&gt;Hi Databricks team,&lt;/P&gt;&lt;P&gt;Quick heads-up and request for guidance. While collaborating on a notebook &lt;STRONG&gt;in my personal workspace&lt;/STRONG&gt;, a colleague who had &lt;STRONG&gt;READ&lt;/STRONG&gt; permission on a workspace-backed Secret Scope was able to &lt;STRONG&gt;delete a secret key&lt;/STRONG&gt; via terminal/CLI from the shared notebook’s attached cluster.&lt;/P&gt;&lt;P&gt;I’m not sure if this is expected or a misconfiguration, but it felt like a privilege escalation tied to sharing from a personal workspace.&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;What we saw (brief):&lt;/STRONG&gt;&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;&lt;P&gt;Scope: workspace-backed, colleague explicitly &lt;STRONG&gt;READ&lt;/STRONG&gt; only&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;Context: notebook shared from &lt;STRONG&gt;my personal workspace&lt;/STRONG&gt;&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;Action: databricks secrets delete --scope &amp;lt;scope&amp;gt; --key &amp;lt;key&amp;gt; by the colleague &lt;STRONG&gt;succeeded&lt;/STRONG&gt;&lt;/P&gt;&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;&lt;STRONG&gt;Questions:&lt;/STRONG&gt;&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;&lt;P&gt;Is this expected when sharing notebooks from personal workspaces, or is it a known issue?&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;Any recommended mitigations (e.g., use shared folders, disable cluster terminal, use Key Vault–backed scopes, ensure CLI uses the caller’s identity)?&lt;/P&gt;&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;Happy to share workspace/cluster IDs and timestamps privately if helpful. Thanks!&lt;/P&gt;</description>
    <pubDate>Tue, 21 Oct 2025 18:42:19 GMT</pubDate>
    <dc:creator>guidotognini</dc:creator>
    <dc:date>2025-10-21T18:42:19Z</dc:date>
    <item>
      <title>Heads-up: collaborator with READ on Secret Scope could delete a key from my shared notebook</title>
      <link>https://community.databricks.com/t5/data-governance/heads-up-collaborator-with-read-on-secret-scope-could-delete-a/m-p/135567#M2641</link>
      <description>&lt;P&gt;Hi Databricks team,&lt;/P&gt;&lt;P&gt;Quick heads-up and request for guidance. While collaborating on a notebook &lt;STRONG&gt;in my personal workspace&lt;/STRONG&gt;, a colleague who had &lt;STRONG&gt;READ&lt;/STRONG&gt; permission on a workspace-backed Secret Scope was able to &lt;STRONG&gt;delete a secret key&lt;/STRONG&gt; via terminal/CLI from the shared notebook’s attached cluster.&lt;/P&gt;&lt;P&gt;I’m not sure if this is expected or a misconfiguration, but it felt like a privilege escalation tied to sharing from a personal workspace.&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;What we saw (brief):&lt;/STRONG&gt;&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;&lt;P&gt;Scope: workspace-backed, colleague explicitly &lt;STRONG&gt;READ&lt;/STRONG&gt; only&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;Context: notebook shared from &lt;STRONG&gt;my personal workspace&lt;/STRONG&gt;&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;Action: databricks secrets delete --scope &amp;lt;scope&amp;gt; --key &amp;lt;key&amp;gt; by the colleague &lt;STRONG&gt;succeeded&lt;/STRONG&gt;&lt;/P&gt;&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;&lt;STRONG&gt;Questions:&lt;/STRONG&gt;&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;&lt;P&gt;Is this expected when sharing notebooks from personal workspaces, or is it a known issue?&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;Any recommended mitigations (e.g., use shared folders, disable cluster terminal, use Key Vault–backed scopes, ensure CLI uses the caller’s identity)?&lt;/P&gt;&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;Happy to share workspace/cluster IDs and timestamps privately if helpful. Thanks!&lt;/P&gt;</description>
      <pubDate>Tue, 21 Oct 2025 18:42:19 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-governance/heads-up-collaborator-with-read-on-secret-scope-could-delete-a/m-p/135567#M2641</guid>
      <dc:creator>guidotognini</dc:creator>
      <dc:date>2025-10-21T18:42:19Z</dc:date>
    </item>
    <item>
      <title>Re: Heads-up: collaborator with READ on Secret Scope could delete a key from my shared notebook</title>
      <link>https://community.databricks.com/t5/data-governance/heads-up-collaborator-with-read-on-secret-scope-could-delete-a/m-p/135576#M2642</link>
      <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://community.databricks.com/t5/user/viewprofilepage/user-id/169029"&gt;@guidotognini&lt;/a&gt;&amp;nbsp;-&amp;nbsp;This is not expected behavior if your colleague truly has only READ and their CLI was using their own identity; deletion requires WRITE/MANAGE on the scope. The most probable explanation is that the CLI call was authenticated as an identity with elevated permissions (either via a misconfigured token/profile or a broader ACL than intended), rather than privilege escalation due to sharing from a personal workspace.&lt;/P&gt;
&lt;P&gt;Can you try the following and check the output? Your colleague should have only read permission, as you stated. It might happen that the group your colleague is in, has manage permission on the scope.&lt;/P&gt;
&lt;LI-CODE lang="markup"&gt;databricks secrets get-acl &amp;lt;scope&amp;gt; &amp;lt;principal&amp;gt; or 
databricks secrets list-acls &amp;lt;scope&amp;gt;&lt;/LI-CODE&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 21 Oct 2025 19:13:29 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-governance/heads-up-collaborator-with-read-on-secret-scope-could-delete-a/m-p/135576#M2642</guid>
      <dc:creator>dkushari</dc:creator>
      <dc:date>2025-10-21T19:13:29Z</dc:date>
    </item>
  </channel>
</rss>

