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

Stack outputs show secrets parameters when parent is exported #2862

Closed
hexmoose opened this issue Jun 21, 2019 · 1 comment · Fixed by #2875
Closed

Stack outputs show secrets parameters when parent is exported #2862

hexmoose opened this issue Jun 21, 2019 · 1 comment · Fixed by #2875
Assignees
Labels
impact/security kind/bug Some behavior is incorrect or out of spec p0 A bug severe enough to interrupt existing work
Milestone

Comments

@hexmoose
Copy link

Pulumi Devs,

Thanks for taking a look at this. I've noticed that attributes of resources that contain a secret value are not encrypted in the stack when the parent resource is exported. However, individual references to that attribute as an export are encrypted. In both examples, the output is correctly masked. My expectation is that the secret never shows up in plaintext in the stack export in either case. This is almost the inverse of this issue: #2756.

To reproduce, setup a new typescript project (using pulumi 0.17.18 and node 12.4.0):

pulumi new typescript --secrets-provider passphrase
npm install --save @pulumi/random

Create a secret:

pulumi config set --secret petPrefix 'super-pet'

Edit index.ts:

import * as pulumi from "@pulumi/pulumi";
import * as random from "@pulumi/random";

const config = new pulumi.Config("secrets-issue");
const secretPetPrefix = config.requireSecret("petPrefix");

// This exposes the `prefix` field in the stack.
export const mypet = new random.RandomPet("mypet", {
    prefix: secretPetPrefix,
});

// This correctly masks/encrypts the secret.
export const myPetPrefix = mypet.prefix;

Create the stack:

pulumi up

Previewing update (dev):

     Type                       Name               Plan
 +   pulumi:pulumi:Stack        secrets-issue-dev  create
 +   └─ random:index:RandomPet  mypet              create

Resources:
    + 2 to create

Do you want to perform this update? yes
Updating (dev):

     Type                       Name               Status
 +   pulumi:pulumi:Stack        secrets-issue-dev  created
 +   └─ random:index:RandomPet  mypet              created

Outputs:
    myPetPrefix: "[secret]"
    mypet      : {
        id       : "[secret]-fluent-seal"
        length   : 2
        prefix   : "[secret]"
        separator: "-"
        urn      : "urn:pulumi:dev::secrets-issue::random:index/randomPet:RandomPet::mypet"
    }

Resources:
    + 2 created

Duration: 1s

If you inspect the stack via pulumi stack export (or by looking at the local stack directly), the text "super-pet" exists in plaintext as an output of mypet but not of myPetPrefix. I would expect it to be ciphertext in all cases.

[...]
    "resources": [
        {
            "urn": "urn:pulumi:dev::secrets-issue::pulumi:pulumi:Stack::secrets-issue-dev",
            "custom": false,
            "type": "pulumi:pulumi:Stack",
            "outputs": {
                "myPetPrefix": {
                    "4dabf18193072939515e22adb298388d": "1b47061264138c4ac30d75fd1eb44270",
                    "ciphertext": "v1:OT/3h49G1Ca046xD:ILG2P3u3pj52qXgRd4708qEMwWE8vgSV+EL5"
                },
                "mypet": {
                    "id": "super-pet-fluent-seal",
                    "length": 2,
                    "prefix": "super-pet",
                    "separator": "-",
                    "urn": "urn:pulumi:dev::secrets-issue::random:index/randomPet:RandomPet::mypet"
                }
            }
        },
 [...]

Thanks for taking a look at this issue! Let me know if I can provide any other information to assist with debugging.

@lukehoban
Copy link
Member

This appears to just be related to exporting the entire resource (which we then JSON serialize). We should make sure that process respects secrets.

Note that #2717 may also impact this case, though I don’t think it’s the cause of this specific issue.

@lukehoban lukehoban added kind/bug Some behavior is incorrect or out of spec impact/security labels Jun 24, 2019
@joeduffy joeduffy added this to the 0.24 milestone Jun 24, 2019
@joeduffy joeduffy added the p0 A bug severe enough to interrupt existing work label Jun 24, 2019
ellismg added a commit that referenced this issue Jun 24, 2019
Our logic to export a resource as a stack output transforms the
resource into a plain old object by eliding internal fields and then
just serializing the resource as a POJO.

The custom serialization logic we used here unwrapped an Output
without care to see if it held a secret. Now, when it does, we
continue to return an Output as the thing to be serialized and that
output is marked as a secret.

Fixes #2862
ellismg added a commit that referenced this issue Jun 26, 2019
Our logic to export a resource as a stack output transforms the
resource into a plain old object by eliding internal fields and then
just serializing the resource as a POJO.

The custom serialization logic we used here unwrapped an Output
without care to see if it held a secret. Now, when it does, we
continue to return an Output as the thing to be serialized and that
output is marked as a secret.

Fixes #2862
ellismg added a commit that referenced this issue Jun 26, 2019
Our logic to export a resource as a stack output transforms the
resource into a plain old object by eliding internal fields and then
just serializing the resource as a POJO.

The custom serialization logic we used here unwrapped an Output
without care to see if it held a secret. Now, when it does, we
continue to return an Output as the thing to be serialized and that
output is marked as a secret.

Fixes #2862
ellismg added a commit that referenced this issue Jun 26, 2019
Our logic to export a resource as a stack output transforms the
resource into a plain old object by eliding internal fields and then
just serializing the resource as a POJO.

The custom serialization logic we used here unwrapped an Output
without care to see if it held a secret. Now, when it does, we
continue to return an Output as the thing to be serialized and that
output is marked as a secret.

Fixes #2862
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
impact/security kind/bug Some behavior is incorrect or out of spec p0 A bug severe enough to interrupt existing work
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants