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

Add documentation for new rootless password rotation workflow for DB Static Roles #28374

Merged
merged 10 commits into from
Oct 7, 2024

Conversation

vinay-gopalan
Copy link
Contributor

Description

Adds documentation for the new workflow in DB Static roles that enables users to onboard DB users onto the Static Roles mechanism without having to configure a root connection.

@vinay-gopalan vinay-gopalan requested a review from a team as a code owner September 11, 2024 21:41
@github-actions github-actions bot added the hashicorp-contributed-pr If the PR is HashiCorp (i.e. not-community) contributed label Sep 11, 2024
@vinay-gopalan vinay-gopalan added pr/no-changelog pr/no-milestone docs and removed hashicorp-contributed-pr If the PR is HashiCorp (i.e. not-community) contributed labels Sep 11, 2024
@vinay-gopalan vinay-gopalan requested a review from a team September 11, 2024 21:41
Copy link

CI Results:
All Go tests succeeded! ✅

Copy link

Build Results:
All builds succeeded! ✅

@VioletHynes VioletHynes added the hashicorp-contributed-pr If the PR is HashiCorp (i.e. not-community) contributed label Sep 16, 2024
@@ -534,6 +534,11 @@ this in order to know the password.
- `username` `(string: <required>)` – Specifies the database username that this
Vault role corresponds to.

- `self_managed_password` `(string)` – <EnterpriseAlert product="vault" inline />
Copy link
Contributor

@fairclothjm fairclothjm Sep 16, 2024

Choose a reason for hiding this comment

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

Sorry to keep nitpicking this PR, but given we don't have plans to add this to any other DBs anytime soon should we move this to the postgres API specific page?

We could do something similar to how we extend the connection config...

## Create static role

In addition to the parameters defined by the Database backend's
[Create static role](/vault/api-docs/secret/databases#create-static-role)
endpoint, this plugin has a number of parameters to further configure a static role.

- `self_managed_password` `(string)` – ...

Copy link
Contributor

Choose a reason for hiding this comment

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

Where we should document it depends on where it's defined, not how its use is limited.

  • If the field is part of the Vault API and recognized as a valid field in a request to the /database/static-roles/:name endpoint, we should define it here and note the limited use.

  • If the field is part of the PostgreSQL plugin API and recognized as a valid field in a request to the /database/config/<postgres_plugin_name> endpoint (or any other endpoint specific to the plugin), we should define it on the PostgreSQL page.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the clarification, @schavis! This field is part of the Vault API, so I opted to define it here and noted its limited use to select DBs.

Copy link
Contributor

@fairclothjm fairclothjm left a comment

Choose a reason for hiding this comment

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

Going to approve this because I don't want to hold it up. However, I added a suggestion to move the self_managed_password field to the DB specific API page.

website/content/api-docs/secret/databases/index.mdx Outdated Show resolved Hide resolved
@@ -534,6 +534,11 @@ this in order to know the password.
- `username` `(string: <required>)` – Specifies the database username that this
Vault role corresponds to.

- `self_managed_password` `(string)` – <EnterpriseAlert product="vault" inline />
Copy link
Contributor

Choose a reason for hiding this comment

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

Where we should document it depends on where it's defined, not how its use is limited.

  • If the field is part of the Vault API and recognized as a valid field in a request to the /database/static-roles/:name endpoint, we should define it here and note the limited use.

  • If the field is part of the PostgreSQL plugin API and recognized as a valid field in a request to the /database/config/<postgres_plugin_name> endpoint (or any other endpoint specific to the plugin), we should define it on the PostgreSQL page.

@vinay-gopalan
Copy link
Contributor Author

@schavis let me know if there are any other changes you think would be appropriate, thanks! 🙏🏼

@vinay-gopalan
Copy link
Contributor Author

@schavis can you please take another look and let us know if this PR needs anything else? Merging is blocked.

@vinay-gopalan vinay-gopalan enabled auto-merge (squash) October 7, 2024 15:49
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.

4 participants