https://pulumi.com logo
Join Slack
Powered by
I've got a deployment, that contains a container s...
# general
b
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
Can you paste in the relevant code? Only the 
data
and 
stringData
fields of a Secret should be marked as secret by default.
b
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
@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
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
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
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
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
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
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
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
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
b
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?
Open in Slack
PreviousNext
Powered by