Hi all I'm trying to set up a cloud SQL instance o...
# google-cloud
Hi all I'm trying to set up a cloud SQL instance on GCP but it requires a password from GCP secret manager - when I try to create the sql USER with the secret using secretmanager.get_secret_version, I get an error on pulumi up about how the secret does not exist - I surmise this is because it's still being created? I thought get_secret_version would wait until the resource was created?
So the
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.
@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?
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?
@prehistoric-activity-61023 line 11 fails
how does it fail? does it throw an exception or sth?
@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...?
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
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
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 🙂.
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.,
). It might be easier to use
to get the ID to pass to
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.
@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
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
here and that part probably works. I assume it complains when it first executes
and I think there’s no way to include
in InvokeOptions. That’s the main reason why I have 2 separated projects for GCP (
where I enable all APIs and configure things such as top-level IAM rules and
where I actually create resources such as cloud sql, gke, memory store etc.). Additionally, I think
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.
@prehistoric-activity-61023 yes indeed, I figured that I violated a pulumi best practice here but this is all good to know - thanks!
I’m glad we could help 🙂
🙌 2