Cloud

TL;DR The key is to start the container with the HOME environment variable set to something writeable, such as /tmp/gcloud. docker run --rm -it --user 1001 -e HOME=/tmp/gcloud gcr.io/google.com/cloudsdktool/cloud-sdk Details The GCP tools automatically setup a GCP config directory which includes a log of all the commands that are run. Typically this is in ~/.config/gcloud/. Out of the box, the container has a user with UID=0 and UID=1000 root:x:0:0:root:/root:/bin/bash ... cloudsdk:x:1000:1000::/home/cloudsdk:/bin/bash Which means, if you either run it by default you end up with UID=0, which exists and has a writeable home, or you are the only user on your system, and start the container with --user 1000, you also end up with a writeable home, and everything works. ...

Update 2023-09-15 Using Control Master This is my preferred approach now, as it is simple to use, and doesn’t come with the added security issues of having authentication keys lying around. It utilises an SSH capability called ControlMaster, which multiplexes multiple SSH sessions over the same connection. Only the initial connection requires authentication, then, all subsequent SSH or SCP calls to the same account+host will use the authenticated connection. Step 1 is to setup you SSH to use ControlMaster. In ~/.ssh/config add ...

Securing any infrastructure means, amongst other things, protecting machines from unnecessary exposure, and restricting remote administration access. While having an SSH port open to the world is sometimes a necessary evil, a preferable approach is to restrict access, via a firewall or security group, to a smaller, more controlled network. If you always administer your systems from a single location - home, office, etc - it is practical to simply whitelist those IP addresses. However, if you are ever working remotely it’ll become necessary to either manually add your current IP address, or use a VPN. ...