https://pulumi.com logo
Powered by
b

bitter-dentist-28132

09/06/2019, 9:02 PM
I've got a deployment, that contains a container spec, that contains an 
envFrom
with a reference to a secret's name. and it seems that makes the entire container spec secret, which means i get an empty output for the diff, so i can't see the image change. any way around that? where's the demarcation of what's marked secret? if i were to pass a 
new k8stypes.core.v1.EnvFromSource
to 
envFrom
instead of an array of hashes, would that work?
g

gorgeous-egg-16927

09/06/2019, 9:07 PM
Can you paste in the relevant code? Only the 
data
and 
stringData
fields of a Secret should be marked as secret by default.
b

bitter-dentist-28132

09/06/2019, 9:20 PM
Copy code
let googleMapsKey = config.requireSecret('googleMapsKey');
const googleMapsKeySecret = new k8s.core.v1.Secret(`google-maps-key-${stackName}`, {
    metadata: { namespace: namespace },
    stringData: {GOOGLE_MAPS_KEY: googleMapsKey},
}, {provider: provider});

const deployment = new ServiceDeployment(`deployment-${stackName}`, namespace, {
    // ...
    envFrom: [{secretRef: {name: googleMapsKeySecret.metadata.name}}],
}, {provider: provider});

export class ServiceDeployment extends pulumi.ComponentResource {
    constructor(name: string, namespace: pulumi.Output<string>, args: ServiceDeploymentArgs, opts?: pulumi.ComponentResourceOptions) {
        super("vantrix:pulumi-library:ServiceDeployment", name, {}, opts);

        const container: k8stypes.core.v1.Container = {
            // ...
            envFrom: args.envFrom,
        };
        this.deployment = new k8s.apps.v1.Deployment(name, {
            // ...
            spec: {
                template: {
                    spec: {
                        containers: [ container ],
                        imagePullSecrets: args.imagePullSecrets,
                    },
                },
            },
        }, { parent: this });
    }
}

export interface ServiceDeploymentArgs {
    // ...
    imagePullSecrets?: pulumi.Input<k8stypes.core.v1.LocalObjectReference>[],
    envFrom?: pulumi.Input<k8stypes.core.v1.EnvFromSource>[];
}
g

gorgeous-egg-16927

09/06/2019, 9:38 PM
@white-balloon-205 @bitter-oil-46081 Any ideas on the cause here? Perhaps related to 
let googleMapsKey = config.requireSecret('googleMapsKey');
? I would expect the Deployment not to be marked secret because it only references the names of secrets, not the secret value directly
b

bitter-oil-46081

09/06/2019, 9:47 PM
Here is what I suspect is happening: Because of https://github.com/pulumi/pulumi-kubernetes/commit/f86e63237f4444f532f9538723837e71f840c410, we mark the 
lastAppliedConfig
property of the metadata bag on the Secret as encrypted (because it would contain the plaintext value of the secret). However, in the languages, we can only track this secretness at the level of Output<T>'s so the single secret property of 
.metadata
taints the entire metadata output, which means when you pull the 
.name
property off of the 
metadata
output, the secretness is transferred to it. We could be smarter about how we taint the Output<T>'s here. Eps in the case where you dot into a nested property like this.
b

bitter-dentist-28132

09/06/2019, 9:50 PM
hmm. well, i can say that if i do a 
pulumi stack export
, the 
lastAppliedConfiguration
is secretized as you say, but the other parts of it are not, except for the 
spec.template.spec.containers
field.
or are you saying that, in this case, the 
spec.template.spec.containers
is the 
Output<T>
?
b

bitter-oil-46081

09/06/2019, 9:58 PM
In this case, I'm taking about the 
googleMapsKeySecret.metadata.name
invocation here. I believe what is happening is that the 
Output<T>
for 
googleMapsKeySecret.metadata
is being treated as a secret because part of the object (i.e. the 
lastAppliedConfig
property that the kubernetes provider added to it) itself is a secret.
b

bitter-dentist-28132

09/06/2019, 10:00 PM
ahhhh ok, i see, that makes sense. but then in that case, how come the "secret-ness" bubbles all the way up to the level of 
containers
?
g

gorgeous-egg-16927

09/06/2019, 10:01 PM
Because you’re accessing 
.metadata.name
in 
envFrom
If the entire 
.metadata
field is marked secret, it will cascade through all the resources that access it
b

bitter-dentist-28132

09/06/2019, 10:04 PM
what's the "boundary" there? other fields within the deployment are not marked secret, which is why i asked if creating a new object for the 
envFrom
field would stop it from bubbling up beyond that level.
g

gorgeous-egg-16927

09/06/2019, 10:04 PM
I’ll open an issue to track. This behavior is obviously overly aggressive, and what you’re doing should work
You should be able to manually set the secret name and use it in the 
envFrom
as a workaround
So right now it’s tainting 
secret
->`envFrom`->`container`->`containers`
b

bitter-dentist-28132

09/06/2019, 10:07 PM
yeah ok, i guess i'll try messing around with different things to see if i can stop it from bubbling up. please let me know the issue number when you file it 🙂
g

gorgeous-egg-16927

09/06/2019, 10:14 PM
b

bitter-dentist-28132

09/06/2019, 11:19 PM
i was able to work around it by doing
Copy code
googleMapsKeySecret.metadata.name.apply(n => {
    const deployment = new ServiceDeployment(`deployment-${stackName}`, namespace, {
        // ...
        envFrom: [{secretRef: {name: n}}],
    }, {provider: provider});
});
is there a more pleasant way to accomplish the same thing, like with 
await
or something?
Powered by