https://pulumi.com
Join Slack
This message was deleted.
# google-cloud
s
This message was deleted.
g
So the 
secretmanager.get_secret_version
call drops the version of the secret, not the value. I think what you want is https://www.pulumi.com/registry/packages/gcp/api-docs/secretmanager/getsecret/, which will wait until the value is available if you use the direct call.
f
@great-queen-39697 thanks for the reply! If I look at the results of getsecret, the "value" of the secret is not there: https://www.pulumi.com/registry/packages/gcp/api-docs/secretmanager/getsecret/#result
The actual 'value' of the secret (secret_data) is in the secret version result: https://www.pulumi.com/registry/packages/gcp/api-docs/secretmanager/getsecretversion/#result
@prehistoric-activity-61023 do you have any insight here btw?
p
I haven’t used GCP secret manager so I’m not sure I can help. I’m working with pulumi right now so I might have find some time to check it out.
Just to clarify, you want to create CloudSQL user with password acquired from GCP secret manager?
Can you paste the code you have right now?
f
@prehistoric-activity-61023 line 11 fails
pulumi gcp creating a cloud sql instance with user.py
p
how does it fail? does it throw an exception or sth?
f
@prehistoric-activity-61023 yes it throws either of two errors: 1. the secretmanager API is disabled, please enable (which I do very early on in my call script) 2. the secret 'DB_PASS' does not exist in secret manager
Again I surmise because the secretmanager hasn't actually created the secret version as yet...?
p
Ok, regarding the first one - that’s a pain in the ass in GCP 😉. If you want to enable API in the same stack, you have to explicitly add 
depends_on
to all resources that rely on this as this dependency cannot be autodetected by pulumi.
💯 1
but I guess (for now) you can workaround that by running 
pulumi up
twice (first it’s gonna enable the service and fail with “API is disabled”, on the second run it should be fine)
Regarding the second one… well, maybe it’s right? Are you sure that 
DB_PASS
already exists in secretmanager?
oh wait… you’re enabling the secretmanager WITHIN that stack, am I right?
it means you’re probably creating the password within this stack as well
if that’s so, can’t you use the password value directly? 🤔
basically, can you describe how you’re creating the secret version?
You most probably can simply reuse this value (and it will implicitly create a dependency graph within pulumi based on Input/Output mechanism) but it will be much easier if you paste some code 🙂.
g
I stand corrected on the correct function call; apologies. Do you find the secret in the UI, by the way? I wonder... if you're creating the secret earlier on in your code, it may be getting a different ID in the system because Pulumi adds a random string to the end of the logical name to avoid collisions (e.g., 
my-secret-123456
). It might be easier to use 
get_secret
to get the ID to pass to 
get_secret_version
p
yeah, auto-naming might be an issue here as well (but in that case, you can always explicitly set the name of the resource)
@fast-arm-63150 I’ll wait for the code snippet where you actually create a secret version.
f
@prehistoric-activity-61023 to answer your questions above 1. yes I have to re-run twice to deal with enabling secretmanager - I do use the depends_on where it is required to build out the dependency graph 2. I am enabling the secretmanager and creating the password within the stack as well! 3. to workaround this I eventually just used the password value directly 🙂 but did want to know what I was doing wrong 4. Here's some code where I actually create a secret version:
@prehistoric-activity-61023 how I create gcp secrets and secret versions
Untitled.py
p
3) I wonder if you should consider this a workaround. If you’re managing the secret using pulumi, I think there’ nothing wrong to pass that value directly. Saving secret to Secret Manager might be a way to securely pass this value to other services (let’s say workload on GKE or some cloud functions).
Ok, you’re using 
depends_on
here and that part probably works. I assume it complains when it first executes 
secretmanager.get_secret_version
and I think there’s no way to include 
depends_on
in InvokeOptions. That’s the main reason why I have 2 separated projects for GCP (
gcp-project-bootstrap
where I enable all APIs and configure things such as top-level IAM rules and 
gcp-project
where I actually create resources such as cloud sql, gke, memory store etc.). Additionally, I think 
get_*
functions are only used when you need to get resources managed outside of your pulumi stack (or to get resources not managed by any IaC at all). In your case, you’re creating the secret and CloudSQL user in the same stack so there’s no need for that and you can pass these values directly.
f
@prehistoric-activity-61023 yes indeed, I figured that I violated a pulumi best practice here but this is all good to know - thanks!
p
I’m glad we could help 🙂
🙌 2
6 Views
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by