Cloud CLIs, kubectl and SSH

Read this when

The agent needs to talk to a cloud account, a cluster or a server.

Cloud credentials reach real infrastructure. OpenMoat keeps their files away from the agent and from the programs it runs, because the agent’s OS sandbox is built from the same policy:

Credentials in	Used by
~/.aws	aws
~/.config/gcloud	gcloud
~/.azure	az
~/.kube	kubectl, helm
~/.docker/config.json	docker login tokens
~/.ssh	ssh and scp key files

So aws s3 ls or kubectl get pods started by the agent go to your agent’s prompt, and even when approved they cannot read the credentials in those files.

The agent runs	Answer
aws s3 ls, kubectl get pods, gcloud config list	defer, then no credential files in the sandbox
aws configure export-credentials, gcloud auth print-access-token, az account get-access-token	deny: they print a token
ssh deploy@myserver.example.com uptime	deny: default.net, an unknown host
curl http://169.254.169.254/	deny: the cloud metadata service

What to do instead

• Run those commands yourself. Ask the agent to write the command or script; run it in your own terminal.
• Call an HTTP API with a brokered token, so the agent never holds it: Keep a token from the agent.
• Use credentials scoped to a sandbox account, never production, if you must let an agent operate infrastructure.

Credentials in environment variables

A variable exported in the shell you start the agent from (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) is passed to the programs the agent runs. The agent cannot print it, but aws started by the agent can use it. Do not start an agent from a shell that holds production credentials.