<?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 SQL Warehouse external (to Databricks) access patterns and suggestions in Warehousing &amp; Analytics</title>
    <link>https://community.databricks.com/t5/warehousing-analytics/sql-warehouse-external-to-databricks-access-patterns-and/m-p/61479#M1209</link>
    <description>&lt;P&gt;Hi All!&lt;/P&gt;&lt;P&gt;Has anyone encountered a situation where we need to setup data access for Unity Catalog tables for read access such as external data marts, dashboard tools and etc.&lt;/P&gt;&lt;P&gt;We are currently using Databricks to serve data to people in our organisation that are not onboarded onto Databricks and trying out the SQL Warehouse JDBC/DBC serving option to integrate traditional relational DB ETL tools and general SQL clients. Which works well, but.....&lt;/P&gt;&lt;P&gt;We need the users to have READONLY access and would like to have this via a non-human service account (through LDAP or AD) or a Databricks Service Principal.&lt;/P&gt;&lt;P&gt;We looking at these options, with the following PRO and CONS:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;&lt;STRONG&gt;A developer uses his/her personal account in Databricks to generate a PAT for their downstream system to use,&amp;nbsp;&lt;/STRONG&gt;works, but provides too much permissions for the users external to the environment&lt;/LI&gt;&lt;LI&gt;&lt;STRONG&gt;Onboarding onto Databricks fully&lt;/STRONG&gt;, will work well, and allow self-generation of PAT for authentication, but we will be giving them access to the environment unnecessarily&lt;/LI&gt;&lt;LI&gt;&lt;STRONG&gt;Onboarding a service account from our AD/LDAP tree,&amp;nbsp;&lt;/STRONG&gt;likely not work as service accounts in our network do not have associated email addresses that can be easily accessed&lt;/LI&gt;&lt;LI&gt;&lt;STRONG&gt;Creating a Databricks service principal and using OAuth for JDBC connection,&amp;nbsp;&lt;/STRONG&gt;may work, but not sure if this is recommended&lt;/LI&gt;&lt;LI&gt;&lt;STRONG&gt;Creating a Databricks User and using OAuth for JDBC Connection&lt;/STRONG&gt;, would practically work, but still require a login? and a valid email address&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;We are trying to leverage our local LDAP/AD group/user setup as much as possible, as its easier and also likely a better way to manage this aligned to the our standards for access management&lt;/P&gt;</description>
    <pubDate>Thu, 22 Feb 2024 13:52:29 GMT</pubDate>
    <dc:creator>dwfchu</dc:creator>
    <dc:date>2024-02-22T13:52:29Z</dc:date>
    <item>
      <title>SQL Warehouse external (to Databricks) access patterns and suggestions</title>
      <link>https://community.databricks.com/t5/warehousing-analytics/sql-warehouse-external-to-databricks-access-patterns-and/m-p/61479#M1209</link>
      <description>&lt;P&gt;Hi All!&lt;/P&gt;&lt;P&gt;Has anyone encountered a situation where we need to setup data access for Unity Catalog tables for read access such as external data marts, dashboard tools and etc.&lt;/P&gt;&lt;P&gt;We are currently using Databricks to serve data to people in our organisation that are not onboarded onto Databricks and trying out the SQL Warehouse JDBC/DBC serving option to integrate traditional relational DB ETL tools and general SQL clients. Which works well, but.....&lt;/P&gt;&lt;P&gt;We need the users to have READONLY access and would like to have this via a non-human service account (through LDAP or AD) or a Databricks Service Principal.&lt;/P&gt;&lt;P&gt;We looking at these options, with the following PRO and CONS:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;&lt;STRONG&gt;A developer uses his/her personal account in Databricks to generate a PAT for their downstream system to use,&amp;nbsp;&lt;/STRONG&gt;works, but provides too much permissions for the users external to the environment&lt;/LI&gt;&lt;LI&gt;&lt;STRONG&gt;Onboarding onto Databricks fully&lt;/STRONG&gt;, will work well, and allow self-generation of PAT for authentication, but we will be giving them access to the environment unnecessarily&lt;/LI&gt;&lt;LI&gt;&lt;STRONG&gt;Onboarding a service account from our AD/LDAP tree,&amp;nbsp;&lt;/STRONG&gt;likely not work as service accounts in our network do not have associated email addresses that can be easily accessed&lt;/LI&gt;&lt;LI&gt;&lt;STRONG&gt;Creating a Databricks service principal and using OAuth for JDBC connection,&amp;nbsp;&lt;/STRONG&gt;may work, but not sure if this is recommended&lt;/LI&gt;&lt;LI&gt;&lt;STRONG&gt;Creating a Databricks User and using OAuth for JDBC Connection&lt;/STRONG&gt;, would practically work, but still require a login? and a valid email address&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;We are trying to leverage our local LDAP/AD group/user setup as much as possible, as its easier and also likely a better way to manage this aligned to the our standards for access management&lt;/P&gt;</description>
      <pubDate>Thu, 22 Feb 2024 13:52:29 GMT</pubDate>
      <guid>https://community.databricks.com/t5/warehousing-analytics/sql-warehouse-external-to-databricks-access-patterns-and/m-p/61479#M1209</guid>
      <dc:creator>dwfchu</dc:creator>
      <dc:date>2024-02-22T13:52:29Z</dc:date>
    </item>
  </channel>
</rss>

