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 identity_token_key to Azure and GCP secret engines #28822

Merged
merged 7 commits into from
Nov 8, 2024

Conversation

Monkeychip
Copy link
Contributor

@Monkeychip Monkeychip commented Nov 1, 2024

  • enterprise tests pass

Description

This PR is the first step to allowing WIF configuration on the Azure and GCP Secret engines—it adds the field identity_token_key when mounting the engine—API for adding to config here. The API we hit for creating a new key is here.

This follows the exact same pattern as the AWS secret engine so the actual changes are minor and test coverage framework was already in place.

AWS PR
that talks about what identity_token_key does/is.

azure-gcp-mount.mov

@Monkeychip Monkeychip added the ui label Nov 1, 2024
@Monkeychip Monkeychip added this to the 1.19.0-rc milestone Nov 1, 2024
@Monkeychip Monkeychip requested a review from a team as a code owner November 1, 2024 17:18
@github-actions github-actions bot added the hashicorp-contributed-pr If the PR is HashiCorp (i.e. not-community) contributed label Nov 1, 2024
Copy link

github-actions bot commented Nov 1, 2024

CI Results:
All Go tests succeeded! ✅

Copy link

github-actions bot commented Nov 1, 2024

Build Results:
All builds succeeded! ✅

@@ -191,6 +191,13 @@ export default class MountBackendForm extends Component<Args> {
this.checkPathChange(value);
}

@action
resetForm(value: string) {
// clears the identityTokenKey and path, not the entire form.
Copy link
Contributor Author

@Monkeychip Monkeychip Nov 1, 2024

Choose a reason for hiding this comment

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

Would argue the flow here could be improved upon, but we do currently handle the full "teardown" in willDestroy. I am simply keeping the previous behavior and adding an extra check for removing the identity_token_key if a user presses the back button.

Copy link
Contributor

Choose a reason for hiding this comment

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

So this is new functionality since right now we don't clear the path value when clicking the back button. Is this intended?

If we want to keep this method I think we should make it more flexible and not pass a value here. A couple options are just calling this.resetForm and then inside this function we could do this.handleIdentityTokenKeyChange = '' Then we could expand it to include additional reset values in the future..

However, I'm not entirely sure we need this functionality...looking at ember data, the param is removed when clicking "back" as it is so it feels superfluous

Copy link
Contributor Author

@Monkeychip Monkeychip Nov 7, 2024

Choose a reason for hiding this comment

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

We do clear the path when they press the back button though it's not super clear by looking at the js file. It was on the hbs file. See here. The empty param is kind of a carry over from how it was done before.

And I had to add this function in because it was failing on a test and then I confirmed locally. If you fill in the IdentityTokenKey and click "Cancel" then choose another Secret engine with this option (say aws and then azure) you'll see it filled in.

Copy link
Contributor

Choose a reason for hiding this comment

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

That line you pointed to clears the mountType not the mount path.

Maybe that's a UX question then - if I was a user and had filled out a form, then meant to select a different WIF engine, I'd want that data to be saved and not cleared when switching to a different engine type. I think this is an edge case, so probably not worth delving into too much. Just my two cents!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, thank you for the clarification. Let me remove this for now, return to previous functionality and then ask design as a follow up.

Copy link
Contributor

@hellobontempo hellobontempo left a comment

Choose a reason for hiding this comment

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

Before approving just want to confirm the anticipated form change by reseting the path value

@@ -134,8 +134,8 @@ const MOUNTABLE_SECRET_ENGINES = [
},
];

// A list of Workload Identity Federation engines. Will eventually include Azure and GCP.
Copy link
Contributor

Choose a reason for hiding this comment

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

👏 thanks for updating this comment!

@@ -232,7 +232,7 @@ export default class SecretEngineModel extends Model {
// no ttl options for keymgmt
optionFields = [...CORE_OPTIONS, 'config.allowedManagedKeys', ...STANDARD_CONFIG];
break;
case 'aws':
case WIF_ENGINES.find((type) => type === this.engineType):
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice and clean way to add this case! 😍

@@ -191,6 +191,13 @@ export default class MountBackendForm extends Component<Args> {
this.checkPathChange(value);
}

@action
resetForm(value: string) {
// clears the identityTokenKey and path, not the entire form.
Copy link
Contributor

Choose a reason for hiding this comment

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

So this is new functionality since right now we don't clear the path value when clicking the back button. Is this intended?

If we want to keep this method I think we should make it more flexible and not pass a value here. A couple options are just calling this.resetForm and then inside this function we could do this.handleIdentityTokenKeyChange = '' Then we could expand it to include additional reset values in the future..

However, I'm not entirely sure we need this functionality...looking at ember data, the param is removed when clicking "back" as it is so it feels superfluous

@@ -206,22 +206,21 @@ module('Integration | Component | mount backend form', function (hooks) {
await render(
hbs`<MountBackendForm @mountType="secret" @mountModel={{this.model}} @onMountSuccess={{this.onMountSuccess}} />`
);
for (const engine of WIF_ENGINES) {
Copy link
Contributor

@hellobontempo hellobontempo Nov 8, 2024

Choose a reason for hiding this comment

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

I actually think this is a good place for this iteration because this is a place where the form logic depends on type since the type affects what fields are rendered

@@ -233,18 +232,17 @@ module('Integration | Component | mount backend form', function (hooks) {
undefined,
`On init identityTokenKey is not set on the model`
);
for (const engine of WIF_ENGINES) {
Copy link
Contributor

Choose a reason for hiding this comment

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

same here

Copy link
Contributor

@hellobontempo hellobontempo left a comment

Choose a reason for hiding this comment

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

Great work! Thanks for the dialog about the testing - just trying to be thoughtful about the tests we write. You definitely are closer to this work than I am and I trust your judgement ⭐

@Monkeychip Monkeychip enabled auto-merge (squash) November 8, 2024 16:07
@Monkeychip Monkeychip merged commit 2c3c585 into main Nov 8, 2024
32 checks passed
@Monkeychip Monkeychip deleted the ui/VAULT-32139/gcp-zure-mount-wif branch November 8, 2024 16:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hashicorp-contributed-pr If the PR is HashiCorp (i.e. not-community) contributed ui
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants