f

    fast-arm-63150

    8 months ago
    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?
    g

    great-queen-39697

    8 months ago
    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

    fast-arm-63150

    8 months ago
    @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

    prehistoric-activity-61023

    8 months ago
    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

    fast-arm-63150

    8 months ago
    @prehistoric-activity-61023 line 11 fails
    p

    prehistoric-activity-61023

    8 months ago
    how does it fail? does it throw an exception or sth?
    f

    fast-arm-63150

    8 months ago
    @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

    prehistoric-activity-61023

    8 months ago
    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.
    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

    great-queen-39697

    8 months ago
    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

    prehistoric-activity-61023

    8 months ago
    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

    fast-arm-63150

    8 months ago
    @prehistoric-activity-61023 to answer your questions above1. 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
    p

    prehistoric-activity-61023

    8 months ago
    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

    fast-arm-63150

    8 months ago
    @prehistoric-activity-61023 yes indeed, I figured that I violated a pulumi best practice here but this is all good to know - thanks!
    p

    prehistoric-activity-61023

    8 months ago
    I’m glad we could help 🙂