-
Notifications
You must be signed in to change notification settings - Fork 6
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
Getting a secret from an imported environment returns [unknown]
#347
Comments
This was reported on the basis of the simplest thing I could get to go wrong. It goes wrong in other situations though.
The key part of this is it was all working Friday night when I ran |
Okay, I have some explanations for what's going on in the original report:
@davemyler I'd love separate reports or more details on the other issues you mention, though. I'm not sure what the concrete issues are there, and more information would be helpful. |
There were quite a few things going wrong when storing secrets in ESC and then pulling them into a Pulumi stack using an import. I've stopped using ESC for secrets for the time being as it was no longer working - so I'm not in a position to record or report on what things were failing. What I can say with certainty however is that this problem was introduced by a change sometime between 12:30 UTC 28th June and 09:30 UTC 1st July. I had been deploying and removing stacks for weeks using ESC prior to that, but on the Monday (1st July) morning it was all broken in various ways. |
Because of this I suspect this all stems from a single underlying issue, so hopefully all will work again once this fix is in place. If any other issues remain afterwards I'll report separately. |
These changes allow clients to request that CheckEnvironment decrypt static secrets rather than treating their contents as unknown. This allows clients to more reliably implement `showSecrets` by supplying a decrypter and setting the `showSecrets` flag to `true`. To acheive equivalent behavior without these changes, the client must decrypt secrets in environment definitions prior to calling `CheckEnvironment` and as part of `LoadEnviroment`. Part of #347.
These changes allow clients to request that CheckEnvironment decrypt static secrets rather than treating their contents as unknown. This allows clients to more reliably implement `showSecrets` by supplying a decrypter and setting the `showSecrets` flag to `true`. To acheive equivalent behavior without these changes, the client must decrypt secrets in environment definitions prior to calling `CheckEnvironment` and as part of `LoadEnviroment`. Part of #347.
These changes allow clients to request that CheckEnvironment decrypt static secrets rather than treating their contents as unknown. This allows clients to more reliably implement `showSecrets` by supplying a decrypter and setting the `showSecrets` flag to `true`. To acheive equivalent behavior without these changes, the client must decrypt secrets in environment definitions prior to calling `CheckEnvironment` and as part of `LoadEnviroment`. Part of #347.
These changes plumb support for showing _all_ static secrets through `esc env get` (rather than only those secrets immediately present in the environment being read directly; i.e. including secrets from imported environments). Note that this support is latent, and the fix will not be user-visible until supporting code is deployed to the ESC API. Part of #347.
These changes allow clients to request that CheckEnvironment decrypt static secrets rather than treating their contents as unknown. This allows clients to more reliably implement `showSecrets` by supplying a decrypter and setting the `showSecrets` flag to `true`. To acheive equivalent behavior without these changes, the client must decrypt secrets in environment definitions prior to calling `CheckEnvironment` and as part of `LoadEnviroment`. Part of #347.
These changes plumb support for showing _all_ static secrets through `esc env get` (rather than only those secrets immediately present in the environment being read directly; i.e. including secrets from imported environments). Note that this support is latent, and the fix will not be user-visible until supporting code is deployed to the ESC API. Part of #347.
These changes plumb support for showing _all_ static secrets through `esc env get` (rather than only those secrets immediately present in the environment being read directly; i.e. including secrets from imported environments). Note that this support is latent, and the fix will not be user-visible until supporting code is deployed to the ESC API. Part of #347.
These changes plumb support for showing _all_ static secrets through `esc env get` (rather than only those secrets immediately present in the environment being read directly; i.e. including secrets from imported environments). Note that this support is latent, and the fix will not be user-visible until supporting code is deployed to the ESC API. Part of #347.
Note: we need to do a CLI release and pull the released code into Pulumi. |
What happened?
When trying to retrieve a config value from one environment that was imported through another, the value returned was
[unknown]
Example
(Commands below are using the Pulumi CLI, but the one that returns the
[unknown]
value is the same with the ESC CLI.)Follow steps:
demo-base
environment:pulumi env init demo-base
demo-dev
environment:pulumi env init demo-dev
demo-dev
environment:pulumi env set demo-base pulumiConfig.myBasePassword "my-base-password" --secret
pulumi env set demo-dev pulumiConfig.myDevPassword "my-dev-password" --secret
pulumi env get demo-base pulumiConfig.myBasePassword --show-secrets --value json
pulumi env get demo-dev pulumiConfig.myDevPassword --show-secrets --value json
pulumi env get demo-dev pulumiConfig.myBasePassword --show-secrets --value json
(Will return
[unknown]
)if you run
pulumi env open demo-dev
that works correctly and the following code works as expected:when
Pulumi.dev.yaml
is as follows:This is what my
demo-base
environment looks like:this is what my
demo-dev
environment looks like:(don't forget to delete the environments when you're done:
pulumi env rm demo-dev -y && pulumi env rm demo-base -y
)Output of
pulumi about
Additional context
No response
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).
The text was updated successfully, but these errors were encountered: