https://pulumi.com logo
#contribute
Title
# contribute
t

thousands-toothbrush-98776

09/02/2023, 12:03 AM
Hi again! When developing a provider, what is the best practice for storing a secret such as an API key that will be used to create/update the resources?
l

little-cartoon-10569

09/03/2023, 11:04 PM
Your build platform should provide some options around this. Since you're using GitHub, that would be Encrypted Secrets: https://docs.github.com/en/actions/security-guides/encrypted-secrets
t

thousands-toothbrush-98776

09/04/2023, 5:17 PM
Hi @little-cartoon-10569 thank you for your response! I’m looking for a way that a user of my provider could store their own API key to a service like Jotform. Unless I’m missing something I don’t think Github is the first choice for that? Perhaps Pulumi config secrets are a best practice in this case?
l

little-cartoon-10569

09/04/2023, 8:09 PM
What's the relationship between your Pulumi stacks and your user? Is it one:one? Secrets in stack files are a viable option for this. You can use GitHub secrets if you want a separate pipeline per stack; I don't think there are branch-level secrets in GitHub, so a branch per stack wouldn't help. You could also move the secrets to a vault somewhere, and store the (non-secret) address of the secret in your Pulumi config.
t

tall-librarian-49374

09/05/2023, 8:06 AM
They would usually be passed to a provider with configuration values or environment variables. The same way you set AWS authentication, for example.
t

thousands-toothbrush-98776

09/05/2023, 6:26 PM
@little-cartoon-10569 Like
pulumi-aws
I expect (hope) many people would use this provider in different configurations and different numbers of people. And not everyone would use GitHub. I’ll look into it though, as well as other vaults. Thank you!
@tall-librarian-49374 That makes sense, thanks!
l

little-cartoon-10569

09/05/2023, 6:54 PM
Yes, all user-specific configuration would need to be passed to the provider as a constructor argument. Your provider mustn't care how the user stores it.
t

thousands-toothbrush-98776

09/09/2023, 3:16 AM
@little-cartoon-10569 I think I have explored enough to ask you for elaboration. Bear with me while I set it up, as I’m a long time Pythoner first time Go-er: As a Pulumi user, I might do something like this in Python to set up some AWS resources in the us-east-2 region:
Copy code
import pulumi_aws
provider = pulumi_aws.Provider("awseast", region="us-east-2")
bucket = aws.s3.Bucket("bucket", ...) # etc
Let’s say I want to modify the pulumi-provider-boilerplate to call a REST API to GET a random number. I want my Python pulumi project to use the same pattern as the AWS provider, by passing api_key to the provider constructor:
Copy code
import pulumi_xyz
provider = pulumi_xyz.Provider("myprovider", api_key="my_api_key")
myrandom = provider.Random("myrandom", length=2)
So my question is, do you know what part of the boilerplate code I would need to change so that (1) I can make my eventual Python code look like that and (2) the provider has a saved api key available at the time
Random.Create()
(in provider/provider.go ) is called?
l

little-cartoon-10569

09/10/2023, 9:11 PM
I don't, sorry. I'm not sure why the provider would even save an API key. Wouldn't it just get an object that talks to the real provider and keep that? Keeping a key in memory is something I generally try to avoid.
t

tall-librarian-49374

09/11/2023, 7:04 AM
cc @ancient-policeman-24615 to help with the native provider setup
t

thousands-toothbrush-98776

09/12/2023, 8:23 PM
Ok, thanks! What do you mean by the “real” provider in this case?
l

little-cartoon-10569

09/13/2023, 10:40 PM
I was trying to distinguish between the provider resource / library (e.g. pulumi-aws, or an instance of
@pulumi/aws/Provider
) and AWS. The aws Provider instance makes a connection to AWS (the "real provider"), but (I hope) it doesn't retain in memory the credentials used to make that connection.