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 'secret' to config #11084

Merged
merged 1 commit into from Oct 24, 2022
Merged

Add 'secret' to config #11084

merged 1 commit into from Oct 24, 2022

Conversation

Frassle
Copy link
Member

@Frassle Frassle commented Oct 19, 2022

Description

Fixes project level config correctly type checking secret values.
Also adds a "secret: true" flag to the config schema to require that the config value is secret (this doesn't currently enforce that the default must be secret because we have no way of setting a secure value in Pulumi.yaml).
This removes the support for pulumi config list/get to show project level defaults, they now purely look at stack config. Ideally we'll add this back in but it needs to be done in such a way that we can correctly validate secure config values, but only initializing the decrypter (and thus asking for passphrases etc) if it's needed for the values that list/get is showing.
By default list doesn't do any decryption just transforming any secure value to the string "[secure]". That clearly won't typecheck in the current system if the key is tagged as a number, but what ever system we devise should allow it to typecheck.

Checklist

  • I have added tests that prove my fix is effective or that my feature works
  • I have run make changelog and committed the changelog/pending/<file> documenting my change
  • Yes, there are changes in this PR that warrants bumping the Pulumi Service API version

@pulumi-bot
Copy link
Contributor

pulumi-bot commented Oct 19, 2022

Changelog

[uncommitted] (2022-10-24)

Bug Fixes

  • [engine] Fix type validation of stack config with secure values.
    #11084

Copy link
Member

@AaronFriel AaronFriel left a comment

Choose a reason for hiding this comment

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

Straightforward change.

I didn't see why the b64 crypter implementation moved, what did I miss?

@Frassle
Copy link
Member Author

Frassle commented Oct 20, 2022

I didn't see why the b64 crypter implementation moved, what did I miss?

It was in pkg, I put moved it to SDK so I could use it for tests there. Most of the other crypters are in that same file.

@Zaid-Ajaj
Copy link
Contributor

I thought CI was flaky but these look like legitimate errors:

=== Errors
cmd/pulumi/up.go:116: github.com/pulumi/pulumi/sdk/v3/go/common/util/result.Errorf does not support error-wrapping directive %w
cmd/pulumi/up.go:360: github.com/pulumi/pulumi/sdk/v3/go/common/util/result.Errorf does not support error-wrapping directive %w
cmd/pulumi/watch.go:122: github.com/pulumi/pulumi/sdk/v3/go/common/util/result.Errorf does not support error-wrapping directive %w

I will try fix 'em myself

@Zaid-Ajaj
Copy link
Contributor

This removes the support for pulumi config list/get to show project level defaults [...]

Ideally we'll add this back in but it needs to be done in such a way that we can correctly validate secure config values, but only initializing the decrypter (and thus asking for passphrases etc) if it's needed for the values that list/get is showing

@Frassle I've done a bit of refactoring to make this work for pulumi config, I think it's OK but would appreciate if you could have a look on it.

@AaronFriel re-requested your review because I've some changes, would appreciate a second glance 😄 🙏

Copy link
Member

@AaronFriel AaronFriel left a comment

Choose a reason for hiding this comment

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

The new changes look good to me - the comment on ApplyProjectConfig was helpful to understand why we're calling it and not just always applying project config.

Also separate the validation and merging of project-to-stack values, to
allow us to apply in values even if they're secure and we don't have an
available decrypter. We can't validate that they're all correct, but it
means at least `config get` can do a best effort retrival for config
values.
@Frassle
Copy link
Member Author

Frassle commented Oct 24, 2022

bors merge

@bors
Copy link
Contributor

bors bot commented Oct 24, 2022

Build succeeded:

@bors bors bot merged commit 8a77eb3 into master Oct 24, 2022
@pulumi-bot pulumi-bot deleted the fraser/configSecret branch October 24, 2022 09:56
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.

None yet

4 participants