https://pulumi.com
Join Slack
I haven’t yet figured out how to set the globally scoped provider, somebody here might know
# getting-started
l
I haven’t yet figured out how to set the globally scoped provider, somebody here might know
c
l
Wait, what you can interpolate environment variables in a stack config like this???
Copy code
${{ env.AWS_REGION }}
Or is that only if the env variable is stored with 
pulumi env
?
c
Or is that only if the env variable is stored with 
pulumi env
?
Yeah that's only if you used Pulumi ESC.
l
Ah that makes sense, had a real headache because we use Doppler for sharing secrets and we basically deploy with
Copy code
doppler run --config prd pulumi up
and as it stands we’re relying on the doppler env variables overriding the machine level credentials at time of execution rather than being explicit about it.
It would be super nice to be able to sync doppler with pulumi env/secrets
Deskypus integration maybe 😉
c
Deskypus integration maybe
Ha, funny you should mention that. I originally wrote Environments for Deskypus thinking of local environments and helping developers switch between environment groups. You can use that to run 
doppler
commands as a source for the values. The environments in Deskypus work a little like Postman's.
It would be super nice to be able to sync doppler with pulumi env/secrets
Possibly. Maybe the Pulumi team would be interested in that integration, though, I doubt it would make sense for them given that Doppler is its own secrets sync service. You might propose that as a feature request in 
pulumi/pulumi
to see if they would consider that.
l
Yeah I mean pulumi has doppler as a provider
In theory, you could read from it in the pulumi handler and construct the cloud provider from it
c
Oh I see. If it has a REST API, you can use 
pulschema
to build a native Pulumi provider for it. https://github.com/cloudy-sky-software/pulschema
👀 1
In theory, you could read from it in the pulumi handler and construct the cloud provider from it
Indeed. That would be a good way to source the secrets from Doppler within Pulumi.
l
We have a ton of services and I’m slightly concerned the team might accidentally deploy ot their personal aws credentials at the moment 😅
I’d really prefer a scenario where we can prevent pulumi from even trying to default to base system credentials
and be explicit in the stacks (via doppler)
c
Let me see how big the Doppler REST API spec is. The thing with cloud providers' OpenAPI spec is that none of them are without errors.
🙌 1
So it's a sizeable API spec and I won't know how "bad" it is unless I run 
pulschema
against it and see what adjustments it might need. The thing with most of these API specs is that they are auto-generated themselves and the generator makes some assumptions that don't work with other code generators. I'll see if I can create a provider for it. Doppler has been on my list of open-source providers that I'd like to create for a while now.
🙌 1
l
That would be awesome, if you want a hand at all let me know. Really liking Pulumi so far, would be a good excuse to look under the hood 👍
c
Yeah for sure. DM me your GH username and I can collaborate with you on building the provider out. I would love help testing it too from someone who would actively use it.
👍 1
Also in the meantime, I am actually curious if you create environments within Deskypus and add variables with values that run doppler commands such as 
$(doppler ...)
, that it would work. In theory, I believe it should just work. So if you get a chance to try that out for your local dev experience, that'd be awesome.
l
Will do 👍
c
Then you'd be able to switch between environment groups for your local terminal session using the tray icon.
l
Generally speaking, why is it not the case that Pulumi allows something like this (assuming it doesn’t 😅)?
Copy code
# Pulumi.dev.yaml
config:
  <provider>.access_key: ${{ FOO_BAR }}
Then
Copy code
FOO_BAR=HELLO pulumi up
Because in such a case, in theory regardless of what you have set in ~/.aws/credentials — it would fail if the explicit variables are not provided, no?
or more concisely, if I’m making an active effort to override credentials at deploy time, can I force Pulumi to ignore machine credentials and fail
I mean, I could always do that in the handler by explicitly checking with 
os.Getenv
in Go for example
^ is this the expected approach?
c
So Pulumi ESC allows interpolating values in your stack config sourced from an Environment. But I don't know if a value within that environment itself can be sourced from an env var though. It does look like you could also _set_ env vars by sourcing values from a Pulumi Environment though. But that's not what you are looking for.
l
I suppose if ESC already provides the general functionality, then in theory a solution would be to provide a mechanism to dynamically source the Environment key value pairs
👍 1
Because then it becomes less of a Doppler specific solution and something more general, for example a “Environment Sourcer” for reading key value pairs from a txt file
c
> Because in such a case, in theory regardless of what you have set in ~/.aws/credentials — it would fail if the explicit variables are not provided, no? On the topic of using explicitly declared providers, you can disable the default provider altogether. As well as for extra security (and sanity) you can also lock specific stacks to only operate against specific AWS account IDs by setting 
aws:allowedAccountIds
provider config option.
😇 1
I suppose if ESC already provides the general functionality, then in theory a solution would be to provide a mechanism to dynamically source the Environment key value pairs
That sounds like a good feature request for 
pulumi/pulumi
:)
l
Aha! Let me take a look
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