Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement WorkbenchManagedCredentialsStrategy for Databricks helpers #382

Open
dbkegley opened this issue Jan 31, 2025 · 3 comments · May be fixed by #384
Open

Implement WorkbenchManagedCredentialsStrategy for Databricks helpers #382

dbkegley opened this issue Jan 31, 2025 · 3 comments · May be fixed by #384
Assignees
Labels
sdk Used for automation

Comments

@dbkegley
Copy link
Collaborator

Problem

The external databricks helpers aren't intuitive to use with workbench yet. The local_strategy=databricks_cli fallback option does not work because workbench can't do an external browser redirect flow. A working alternative is to use pat_auth instead, but that's not obvious because workbench managed credentials use an oauth token, not a PAT. (pat_auth just sets a static bearer token on the auth header so it works the same, but how is a user supposed to know that?)

Proposal

We should implement a posit.connect.external.databricks.PositWorkbenchManagedCredentialsStrategy to make it more obvious to users how they should use managed workbench credentials in a piece of content that is going to be deployed to Connect.

Option 1:

session_token = headers.get("Posit-Connect-User-Session-Token")

cfg = Config("workbench")
workbench_strategy = PositWorkbenchManagedCredentialsStrategy(cfg)

posit_strategy = PositCredentialsStrategy(
    local_strategy=workbench_strategy,
    user_session_token=session_token,
)
cfg.credentials_strategy = posit_strategy

There's still some awkwardness here though. Using local_strategy=workbench_strategy would not work locally because the "workbench" managed databricks profile wouldn't exist in the config. Also the need to modify cfg.credentials_strategy feels bad.

Option 2: prefer a more explicit configuration

session_token = headers.get("Posit-Connect-User-Session-Token")

posit_strategy = PositCredentialsStrategy(
    local_strategy=databricks_cli,
    workbench_strategy=PositWorkbenchManagedCredentialsStrategy(Config("workbench"))
    user_session_token=session_token,
)

cfg = Config(
    host=DATABRICKS_HOST_URL,
    credentials_strategy=posit_strategy,
)
...

This is better but the use of the Connect strategy is still non-obvious. How does the caller know if it will do a client credentials flow or a viewer auth flow?

Option 3: an even more explicit configuration

posit_strategy = PositCredentialsStrategy(
    local_strategy=databricks_cli,
    workbench_strategy=PositWorkbenchManagedCredentialsStrategy(Config("workbench"))
    connect_strategy=PositViewerCredentialsStrategy(headers.get("Posit-Connect-User-Session-Token"))
)

cfg = Config(
    host=DATABRICKS_HOST_URL,
    credentials_strategy=posit_strategy,
)
...
@dbkegley dbkegley self-assigned this Jan 31, 2025
@github-actions github-actions bot added the sdk Used for automation label Jan 31, 2025
@tdstein
Copy link
Collaborator

tdstein commented Jan 31, 2025

I prefer option 3 since I assume most people will copy and paste from our documentation.

@dbkegley
Copy link
Collaborator Author

I think that's my preference as well. It does require the most code changes and maybe isn't backwards compatible (not sure yet) but I like that it's the most explicit and obvious to the caller which strategy will be used in which environment. It also provides the most control to mix different options. There's nothing stopping the user from doing pat_auth for both local and workbench if that's what they want to do

@kmasiello
Copy link

I like option three as well. It was confusing to me before why the Connection strategy was just implied. Thank you for putting these thoughts together!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sdk Used for automation
Projects
None yet
3 participants