To all those who worked on ESC, great job! I spen...
# esc
s
To all those who worked on ESC, great job! I spent a lot of time with it over the weekend and find it's a great solution for externalizing config and accessing secrets from a secret store. My only wish is that the OIDC configuration was more automated. It was a bit ironic to have to click through a bunch of Google web console screens in order to do set up for Pulumi. :-)
r
We do have some code examples (more in the examples repo): ā€¢ Python AWS ā€¢ Python GCP But we're not doing a great job of surfacing these in our docs I think
s
I saw those, but I'm not a Python person and they looked more complicated than clicking through 50 fields on GCP we console. I'm really thinking of a much higher level abstraction. Something like:
Copy code
gcp:
  oidc:
    identity-pool: $project-id-pool
    service-acct: $project-$stack-svc-acct
    roles: [owner]
Then, let Pulumi spin up an identity pool and service account with the specified role(s). I know that's easier said than done. :-)
r
šŸ˜„ you gotta have the credentials to spin up the infra to provide the credentials šŸ˜„
but i hear ya! appreciate the feedback.
s
I know, that's what's so weird about it. I'm used to IAC where I get an API secret/key, and I'm off to the races. With ESC, I was manually creating identity pools, service accounts, yada yada, and it all had a very non Infrastructure as Code feel to it.
s
Would non-Python examples of creating the OIDC components via Pulumi be helpful? What language(s) would be most useful to you?
s
Maybe a bit. It probably has a lot of inherent complexity, so any of the languages will probably be a tough slog. I really think an IaC solution might be the wrong level of abstraction for this one-off activity. It makes more sense to be at the command line level; e.g.
Copy code
pulumi env init myOrg/dev --oidc=google
Then, a guided workflow would take over:
Copy code
Identity pool name (myorg-dev-pool-id):
Service account name:(myorg-dev-svc-account):
Service account roles: (owner):
Include IAC subject (n/Y):
This would then do all the resource provisioning behind the scenes using security api key credentials, or a Google cloud console web login temporary token, or whatever. (I'm not sure about this part.) If an existing resource name is given then the user can be asked if they want to modify it or replace it. I'm not trying to solution this in Slack, just trying to set the right level of abstraction for this OIDC setup activity.
s
Understood---thank you for the feedback!
s
You're welcome. In no way is my suggestion meant to criticize ESC. I absolutely love this new-ish capability!
s
Honest feedback is the only way to improve, so thank you for providing honest feedback!