Skip to content

[python] Add Secret management module in apache_beam.utils.secret - #39636

Open
shunping wants to merge 4 commits into
apache:masterfrom
shunping:secret-manager-1
Open

[python] Add Secret management module in apache_beam.utils.secret#39636
shunping wants to merge 4 commits into
apache:masterfrom
shunping:secret-manager-1

Conversation

@shunping

@shunping shunping commented Aug 5, 2026

Copy link
Copy Markdown
Collaborator

Description

Introduces apache_beam.utils.secret to centralize secret management in the Python SDK.

Changes:

  • Derived a new Secret base class and implementations (RawSecret, GcpSecret, and GcpHsmGeneratedSecret) from the existing secret classes defined in util.py used by GBEK.
  • Added factory methods Secret.from_spec() and Secret.from_option_string().
  • Re-exported classes in apache_beam.transforms.util for backwards compatibility.
  • Added unit tests in secret_test.py and updated util_test.py.

@github-actions github-actions Bot added the python label Aug 5, 2026
Comment thread sdks/python/apache_beam/utils/secret.py Fixed
Comment thread sdks/python/apache_beam/utils/secret.py Dismissed
@shunping

shunping commented Aug 5, 2026

Copy link
Copy Markdown
Collaborator Author

r: @damccorm

@shunping
shunping marked this pull request as ready for review August 5, 2026 19:31
@github-actions

github-actions Bot commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

Stopping reviewer notifications for this pull request: review requested by someone other than the bot, ceding control. If you'd like to restart, comment assign set of reviewers

Comment thread sdks/python/apache_beam/utils/secret.py Outdated
For example, 'type:GcpSecret;version_name:my_secret/versions/latest'
would return a GcpSecret initialized with 'my_secret/versions/latest'.

Deprecated: Use :meth:`from_option_string` instead.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason to deprecate this? Is it just a naming change?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it is a name change for consistency with the new function from_spec(), since it is already released, I think using a deprecate path is better than directly changing that and causing breaking change immediately. WDYT?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason for the name change?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think when it comes to a constructor, from_option_string or from_option is more pythonic than parse_secret_option. Also it is consistent with the new from_spec function.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think when it comes to a constructor, from_option_string or from_option is more pythonic than parse_secret_option

This is probably true, but that also probably doesn't make it worth taking on the extra cost of having a deprecated method (that we'll either have forever or will eventually remove in a breaking change).

Also it is consistent with the new from_spec function.

I think we might want to avoid this naming anyways because it is similar to

but not actually referencing the same kind of spec. But it also isn't clear to me why we need this anyways

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can put that logic of parsing json representation inside parse_secret_option, but I think it is clearer to have a separate function.

If from_spec is not a good name, maybe we can use from_json?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should it be a public method? Maybe _from_json?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be public. We will use it to parse the password json string in jdbcio and others.



class FakeSecret(beam.Secret):
class FakeSecret(beam.utils.secret.Secret):

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do all of these tests still belong in this file? Should they be moved if we're doing a refactor into a new module?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will refactor the secret related to the new test file of the module, but GBEK tests will stay in util_test.py.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FakeSecret is actually staying in util_test.py because it is only used by GBEK tests.

return pcoll | 'RemoveDuplicates' >> Distinct()


class Secret():

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR mixes a bunch of non-functional changes (moving from one directory to another while retaining imports, renaming methods) and some smaller targeted functional changes. This makes it difficult to review because its hard to identify what actually changed, and if it does introduce issues it will be harder to track them down as a result. Could we split this change into 2 changes, one to move things into the utils directory and one to make any additional changes to the classes themselves? This could still be 2 commits in the same PR or it could be 2 PRs.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True. Let me split it into two commits then.

@shunping shunping Aug 7, 2026

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

  • Commit ba1e7e is the non-functional moving part.

  • Commit d4c38b6 and 1348753 are to add the new apis and tests.

  • Commit 45bb552 is to refactor the existing parse_secret_option.

PTAL!

There is no functional changes in this commit. We also re-export
the secret classes in apache_beam.transforms.util for backward
compatibility.
@shunping
shunping requested a review from damccorm August 7, 2026 16:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants