https://pantsbuild.org/ logo
Join Slack
Powered by
Hey team, Looking at config issues when pushing d...
# development
c
Hey team, Looking at config issues when pushing docker images, I’m wondering about what approach would be most suitable (see https://pantsbuild.slack.com/archives/C046T6T9U/p1642075724264000?thread_ts=1642008872.220800&cid=C046T6T9U)
My concern is about the hermecity of relying on too much configuration from the machine, while on the other hand, this is the kind of configuration you don’t want to check in, so it needs to come from “some where else” any how.
👍 1
The easy thing is to set/inherit HOME and be done with it, but is that an OK approach?
f
The easy thing is to set/inherit HOME and be done with it, but is that an OK approach?
something to be aware of: that would work with local execution, but would not work with remote execution.
➕ 1
✔️ 1
but I imagine remote execution probably shouldn’t be used for pushing docker images in any event.
h
Because it would mean storing credentials in the remote workers, which is a security risk?
f
that and just configuring remote machines to have the credentials in the first place
👍 1
h
Btw, the process can already access ~/.aws/credentials. Pants can't (currently) stop the process from reaching out to any arbitrary file on the machine. It just throws off relative paths by running in 
/tmp
So I don't think you need to do anything new to get ~/.aws/credentials working. You only need to set up 
env
appropriately like to get 
sh
discoverable
c
but would not work with remote execution
not sure that would be an issue here, though, as the 
publish
processer are run as interactive processes, which implies local, iiuc?
Actually, I think remote execution might trip up a lot in this case, as if you build the docker image on a remote machine, that image is “stuck” there, as we don’t currently export the image to capture it in a digest.
So, perhaps the 
docker push
ought to be remotable too.. and work with exported images from a previous build step.. 🤔
So I don’t think you need to do anything new to get ~/.aws/credentials working.
Exactly.. but I guess it won’t know what 
~
should expand to unless HOME env var is set?
h
Yeah that's true
n
Not sure I follow entirely, but FWIW, you would probably set AWS config via env variables when working with remote machines / CI, rather than the config files. E.g. 
AWS_ACCESS_KEY
, 
AWS_SECRET_ACCESS_KEY
, 
AWS_DEFAULT_PROFILE
and the like. This would obviously work locally as well as a workaround but it’s just another step to manage. In my org, we have AWS access tied to enterprise SSO. We use a tool which reads the config file, uses chromium to login and scrape the SAML cookie, does an API call to AWS, gets an access token, and saves that to 
~/.aws/credentials
. For Jenkins, we have an IAM service account which can assume a role, and the Jenkins plugin handles setting the env vars.
👍 2
Open in Slack
PreviousNext
Powered by