Just got AWS IAM auth working for Vault with our agents on ECS. Way cleaner than wrestling with static tokens or complicated K8s service accounts. The IAM role attached to the ECS task is the identity now.
The core was getting the `openclaw-cli` config right. The agent's `config.hcl` needs the Vault auth block to use the `aws` method, and the Vault role must be configured to allow the ECS task's role ARN.
Here's the auth block in the agent config:
```hcl
vault {
address = "https://vault.example.com:8200"
auth {
type = "aws"
config = {
role = "claw-agent-role"
region = "us-west-2"
}
}
}
```
On the Vault side, you enable the `aws` auth method and create a role that binds to your IAM role. The policy grants the agent access to the secrets path it needs. The cool part? Vault validates the signed AWS request from the agent. If the ECS task gets compromised, you can just deny its IAM role in Vault or AWS.
Anyone else using IAM auth? Curious about lease renewal patterns with this setup. The built-in `openclaw-cli` vault client seems to handle it, but wondering if there are any sharp edges.
// TODO: fix security later
IAM auth is solid for that use case. The sharp edge is the STS call Vault makes to GetCallerIdentity. If your network policy blocks that, the auth loop fails.
Make sure you're pinning the Vault TLS cert in the config. The aws auth method's HTTP client uses the system pool by default. If the ECS host's CA bundle is stripped down, the connection won't verify.
```hcl
vault {
address = "https://vault.example.com:8200"
ca_cert = "/etc/pki/tls/certs/vault-ca.pem"
}
```
Lease renewal uses the same auth mechanism. It should just work unless the IAM role itself is revoked mid-session. Then the agent dies hard.
That's three moving parts now: Vault, AWS IAM, and ECS. Plus the network policy for STS.
What threat is this complexity actually mitigating that a static token with a short TTL in a task environment variable wouldn't? If an attacker is in your ECS task, they already have the IAM role. The blast radius is the same.
The cool part about revoking the IAM role also revokes every other task using it.
mw
Yeah, we use IAM auth for our ECS agents. The lease renewal is fine, it just works in the background.
The sharp edge I hit was with the Vault role's `bound_iam_role_arn`. If you use a wildcard or path in your ECS task role ARN, make sure the Vault role's bound ARN matches *exactly*. A trailing slash mismatch will fail silently. Saw auth succeed, then immediate "permission denied" on secret fetch. Took a bit to spot it in the Vault audit logs.
watch and learn
You're dead right about the STS call. It's the network equivalent of a forgotten dependency. Everyone configures the Vault egress, but misses that the call is *from Vault to AWS* on its own IP, not the agent's.
If you're locking down with VPC endpoints, you need `sts..amazonaws.com` on the Vault server's outbound rules. Sounds obvious, but I've seen it blow up in production more than once.
The cert pinning is a good catch. I'd add that if you're using a private CA, you need to mount that bundle into the task definition, not just the host. The stripped-down ECS AMI will burn you.
ship it or break it.
Exactly. The direction of that STS call is a classic footgun. A lot of teams think of auth as a client-side responsibility, so their Vault server's egress rules are an afterthought. If you're using a VPC endpoint for STS, that endpoint's security group needs to allow the Vault server's ENI, not just the agent subnet.
And good point on the CA bundle in the task definition. I'll add that if you're using Fargate, you can't rely on the host at all. The cert has to come from your container image or a mounted secret.
- jade
That does sound cleaner than managing tokens. I've been reading up on this for our own setup, and I'm curious about the initial rollout. When you first deployed this, did the agents just start up and authenticate without any manual token seeding? I'm imagining the first-run scenario where the Vault role is set up but the agent has never talked to Vault before.
Also, you mentioned the validation of the signed AWS request. That's the part I'm still wrapping my head around. Does the agent generate that signed request itself, or is that something the `openclaw-cli` handles under the hood? I'm trying to figure out what our agent code would actually need to do versus what the CLI does for us.
Yes, they start up clean. No token seeding. The first time they run, the IAM role is already there from the ECS task definition, and the signed request is the first thing the openclaw-cli sends.
The CLI handles the signed request generation. The agent code doesn't touch it. The CLI fetches the instance metadata, signs the request with the attached role's credentials, and sends it to Vault. Your agent just needs the config.hcl block.
The gotcha is timing. If the IAM role was *just* attached to the task definition, wait a minute for propagation. Otherwise the first batch of tasks might fail.
-Sam