https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
b
That should modify the state and without changing the resource... what did the pulumi up output show here?
r
In general I would prefer that this is done by default, especially for kubeconfig and random password.
I did that already some days ago, but if I remember correctly, it didn’t display any change at all.
I’m using a component resource around a service principal, app registration, service principal password and the random password resources, so I did this change inside my component resource. I export the 
servicePrincipalPassword.value
(which was filled by the randomPassword.result value inside the component)
b
ah I believe when using custom resource you would need to mark it as secret inside the custom resource
WRT RandomPassword, there is an open bug around this that is being discussed right now https://github.com/pulumi/pulumi-terraform-bridge/issues/10
👌 1
r
Copy code
this.randomPassword = new random.RandomPassword(`${name}-sp-random-pw`, {
  // omitted
},
{ 
    parent: this,
    additionalSecretOutputs: ['result'] 
});

this.spPassword = new azuread.ServicePrincipalPassword(`${name}-sp-password`, {
    servicePrincipalId: this.servicePrincipal.id,
    // HERE ....
    value: this.randomPassword.result,
    endDate: "2034-01-20T00:09:00Z",
},
{parent: this});


// thats on top of the resource

public readonly spPassword: azuread.ServicePrincipalPassword;


// thats what's using the resource and exporting the value

export const acrPass = acrPushApp.spPassword.value;
So the 
additionalSecretOutputs
would only kick in after the resource was created, so that this information is missing at the point when I’m handing it into the 
ServicePrincipalPassword
?
b
No, the additional secret outputs should be able to be changed at any point
I can see that it works right now with 2 passes in a simple program locally
first, just creating the RandomPassword
then adding it
and it just updates the state
r
There is one indirection on my side, as for this ComponentResource I’m exporting the second usage of the password. If you check my code sample above, the 
additionalSecretOutputs
is on the `RandomPassword`’s 
result
property. This property is handed into the 
ServicePrincipalPassword
and the `ServicePrincipalPassword`’s value is what is accessed in the index file.
So maybe the `RandomPassword`’s 
result
is marked correctly but adding the 
additionalSecretOutputs
afterwards isn’t propagated down to the 
ServicePrincipalPassword
resource.
I just ran that code again and still have 
acrPass
in my stack output unencrypted.
The original 
RandomPassword
resource is encrypted but it is not propagated to the 
ServicePrincipalPassword
.
b
Well the secret output is on the randomPassword resource - you would also need to add it to the ServicePrincipalPassword - it will be passed as a secret, but you are not telling the engine that the output of that resource needs to be a secret
Of course, this is something that should be handled from the TF Schema in the issue linked above but for now, you can mark it in as many places as you need to to nsure you are confident nothing gets leaked
r
Of course, I can mark it in every spot it is used but I thought that was propagating correctly in other cases. Will have a deeper look again - I’m pretty sure that worked that way in other constellations…
Okay. So a different spot where that worked was the 
azure.sql.SqlServer
. Am I right in assuming that this was not propagated using the 
additionalSecretOutputs
but rather because the 
SqlServer
handles it’s properties correctly, treating 
administratorLoginPassword
as secret on its own?
To avoid putting it everywhere down the chain, I can wrap the value in a Secret and work with that? I’ll try that here…
Okay, that also didn’t have an effect. So I’ll put that additional 
additionalSecretOutputs
to the 
ServicePrincipalPassword
and leave the out the rest…
Thanks for your advice!
2 Views
Open in Slack
PreviousNext
Powered by