Skip to content

Add private_key auth method to snowflake query runner #7371

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

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

adrianoesch
Copy link

@adrianoesch adrianoesch commented Mar 12, 2025

What type of PR is this?

  • Refactor
  • Feature
  • Bug Fix
  • New Query Runner (Data Source)
  • New Alert Destination
  • Other

Description

Snowflake will soon require private key authentication for service users without multi factor authentication (see announcement). This PR makes snowflake configurable with a private_key.

How is this tested?

I would need guidance on how you want this tested.

  • Unit tests (pytest, jest)
  • E2E Tests (Cypress)
  • Manually

Related Tickets & Documents

I could only find this discussion.

@adrianoesch adrianoesch changed the title add private_key auth method for snowflake query runner Add private_key auth method for snowflake query runner Mar 12, 2025
@adrianoesch adrianoesch changed the title Add private_key auth method for snowflake query runner Add private_key auth method to snowflake query runner Mar 13, 2025
@adrianoesch
Copy link
Author

i've tested it locally, let me know what kind of tests you want for this.
image

@nijave
Copy link

nijave commented Mar 17, 2025

Thanks!! Just updated our instance to this branch and it's working perfectly

@sh47267
Copy link

sh47267 commented Apr 2, 2025

@adrianoesch
Does it support passphrase-protected private keys?

@adrianoesch
Copy link
Author

hi @sh47267

Does it support passphrase-protected private keys?

it doesn't yet, because i don't understand the motivation behind storing an encrypted string with the password in the same place. but it could easily be added to load_pem_private_key (see here)

@sh47267
Copy link

sh47267 commented Apr 7, 2025

@adrianoesch

You're right — I realize now that without separating the passphrase from the key file, it doesn't really provide any additional security. There might still be demand for it, but thanks for the clarification for now.

@uofifox
Copy link

uofifox commented Apr 24, 2025

Any updates here? We're using redash in my org and trying to get ahead of the snowflake requirements/mandates. We're on an older version of redash anyway and we're holding until a version of redash has this fix on it.

@adrianoesch
Copy link
Author

hi @uofifox , we need the attention of one of the maintainers to merge this into the main branch. as this is an open-source project, one can expect this to take some time. in the meantime, @nijave seems to have had success deploying this branch in his org. also, snowflake allows you to continue working with passwords for user with type LEGACY_SERVICE until nov 2025 (see here).

@uofifox
Copy link

uofifox commented Apr 28, 2025

Thanks for the update, and while the delay in enforcement is not until November, these kinds of things have a way of slipping your mind until its too late. Also note, I noticed you don't have the ability to support encrypted private keys. Most of the other platforms I used actually won't accept the private keys unless it is encrypted. Agree its a bit overkill, but to keep it standard for our group we've just by default encrypted the private key.

@adrianoesch
Copy link
Author

any chance you can unblock us here @arikfr ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants