-
Notifications
You must be signed in to change notification settings - Fork 8
Add option to reach data download token from b64 SA keys #165
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
Closed
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,4 @@ | ||
| - bump: patch | ||
| changes: | ||
| added: | ||
| - Support for base64-encoded Google service account keys. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -11,7 +11,7 @@ authors = [ | |
| {name = "PolicyEngine", email = "[email protected]"}, | ||
| ] | ||
| license = {file = "LICENSE"} | ||
| requires-python = ">=3.6" | ||
| requires-python = ">=3.10" | ||
| dependencies = [ | ||
| "policyengine_core>=3.10", | ||
| "policyengine-uk", | ||
|
|
@@ -20,7 +20,12 @@ dependencies = [ | |
| "google-cloud-storage (>=3.1.0,<4.0.0)", | ||
| "microdf_python", | ||
| "getpass4", | ||
| "pydantic" | ||
| "pydantic", | ||
| "google-auth>=2.40.3", | ||
| "google-auth-oauthlib>=1.2.2", | ||
| "google-auth-httplib2>=0.2.0", | ||
| "google-api-python-client>=2.172.0", | ||
| "click>=8.2.1", | ||
| ] | ||
|
|
||
| [project.optional-dependencies] | ||
|
|
||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question, blocking: Have you looked at all into Google Secrets Manager?
An option I've found that we could use would be, instead of having us create individual service accounts for customers, we could generate our own API keys and then use Google Secrets Manager to store these keys and pass & validate them via SHA256 encryption. This seems a bit more akin to what you're seeking to do. It also gives us more granular control over which datasets this enables, as we can store richer metadata with the key (imagine one day we create another type of limited-access dataset that we don't want these customers to access).
I have a Claude chat here describing Google Secrets Manager, as well as other options that may be less desirable (e.g., JWT tokens). The most relevant portions are toward the end. Curious to hear your thoughts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We would have to build some other service and host it to authenticate right though?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I need to understand our use case better here. I don't really want to manage service accounts for external users or force the user to authenticate using a specific mechanism.
Is there a reason we can't have them provide a gmail account or service account that they own/manage and then grant it permission to access the bucket?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason is that we want to keep the process of running code that downloads the microdata simple. A single microdata access token as an env var is as simple as it gets