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

Feature: Send secrets to Secrets-Store-Driver ("write_secrets" bool flag) #89

Merged
merged 13 commits into from
Jun 1, 2021

Conversation

manedurphy
Copy link
Contributor

Which issue does this PR address?
#88

What does this feature/enhancement do?
By setting the write_secrets flag to false, the provider sends secrets to the Secrets-Store-Driver instead of writing to file system.

Note: You will see that I've commented some code out where I made changes, as well as a "change here" comment in several places. I intend to remove these once I have received a review and the changes are ready for merging. I will also squash the changes into one commit.

I did want an opinion on MountSecretsStoreObjectContentResponse struct I made, I was wondering if there were better practices I could be following there. I was also wondering if I should upgrade the version of Go to 1.16.3?

@hashicorp-cla
Copy link

hashicorp-cla commented May 4, 2021

CLA assistant check
All committers have signed the CLA.

Copy link
Contributor

@tomhjp tomhjp left a comment

Choose a reason for hiding this comment

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

Thanks for the contribution! Generally looks pretty good to me so far, and thanks for the bug fix in there.

There is some unfortunate flakiness in the integration tests that I've had trouble reproducing outside of CI, although the failure in this PR looks systematic and likely related to the CSI driver version update. Line 182 in provider.bats expects two owners, and I think we may now expect 1 due to kubernetes-sigs/secrets-store-csi-driver#493, although I haven't fully dug into that.

Feel free to self-review on GitHub to start off discussions about specific questions, now that the PR's open that may be a better workflow for you than the code comments.

Some of my comments are suggesting slightly broader improvement as well, LMK what you think.

In terms of things we should add before landing:

  • Some test coverage - as discussed offline this may be a little tricky and we can sync some more about the approach
  • A plan for documentation - I think we should probably add a page to https://www.vaultproject.io/docs/platform/k8s/csi/ for command line flags at this stage, I can help you sort that with a PR on the hashicorp/vault repo.
  • A changelog note

internal/provider/provider.go Outdated Show resolved Hide resolved
internal/provider/provider.go Outdated Show resolved Hide resolved
internal/provider/provider.go Outdated Show resolved Hide resolved
internal/provider/provider.go Show resolved Hide resolved
internal/provider/provider.go Outdated Show resolved Hide resolved
internal/server/server.go Outdated Show resolved Hide resolved
.circleci/config.yml Outdated Show resolved Hide resolved
main.go Outdated Show resolved Hide resolved
@manedurphy
Copy link
Contributor Author

Added some of the recommended changes, as well as tried to isolate the problem from the breaking test (test 2 in bats)

Changes:

  1. Removal of handleMountRequest in server.go. The response in MountSecretsStoreObjectContent now has return of type *pb.MountResponse
  2. In order for test 2 in provider.bats to pass, the length of the ownerReferences array had to be changed to 1. At no point did it have more than 1 owner reference, it just had the ReplicaSet from the nginx deployment. I am wondering other object is expected to act as an owner to this secret?

Appreciate the feedback

@tomhjp tomhjp mentioned this pull request May 18, 2021
Copy link
Contributor

@tomhjp tomhjp left a comment

Choose a reason for hiding this comment

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

Thanks for the updates, the code is looking good, just a few minor follow up suggestions. I think the biggest thing left to address is tests. I need to give that some more thought on how best to cover this feature while not abandoning the old code path, but I'm open to suggestions.

internal/provider/provider.go Outdated Show resolved Hide resolved
// MountSecretsStoreObjectContent mounts content of the vault object to target path
func (p *provider) MountSecretsStoreObjectContent(ctx context.Context, cfg config.Config, writeSecrets bool) (*MountSecretsStoreObjectContentResponse, error) {
func (p *provider) MountSecretsStoreObjectContent(ctx context.Context, cfg config.Config, writeSecrets bool) (*pb.MountResponse, error) {
versions := make(map[string]string)
Copy link
Contributor

Choose a reason for hiding this comment

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

May as well make this of type []*pb.ObjectVersion and remove ov now that versions and ov both get created in the same function.

internal/provider/provider.go Outdated Show resolved Hide resolved
test/bats/provider.bats Outdated Show resolved Hide resolved
main.go Outdated Show resolved Hide resolved
main.go Outdated Show resolved Hide resolved
Copy link
Contributor

@tomhjp tomhjp left a comment

Choose a reason for hiding this comment

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

LGTM, thanks for the contribution! I've successfully run the tests with this feature enabled, and I'll follow up separately with another PR to automate that test coverage.

@tomhjp tomhjp merged commit a5dbd65 into hashicorp:master Jun 1, 2021
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.

3 participants