A Leaked Token, a Contractor, and Wide-Open Ports
A 14-person engineering team operates about 40 Compute Instances and one LKE cluster under a single Akamai Cloud account. Automation runs on one API token with read/write across all resource types; it is stored as a repository secret in GitHub Actions and was also pasted into a shared Slack channel three days ago during an incident. A contractor joins for six weeks to deploy application changes only and must not delete volumes, resize instances, or view billing. Cloud Firewalls currently allow 0.0.0.0/0 to ports 22, 80, and 443 on every instance, and SSH password authentication is enabled because key distribution was annoying. Nobody has reviewed audit logs. The account owner is a shared root login kept in a password manager.
1. Order the response to the leaked token. Justify what happens first and why.
Read the worked answer
1. Revoke the token now. Revocation is instantaneous and reversible in cost; every hour it lives is exposure. Do this before investigating.
2. Re-key the pipeline with a new token, rotate the repository secret, and sweep the Slack history and any forks or logs where the value was echoed.
3. Scope the blast radius. Pull audit logs for the token's lifetime and look for create/delete on instances and volumes, firewall rule changes, new users or tokens, and outbound image exports. Three days of unrestricted read/write is enough to matter.
4. Remediate what you find - restore or rebuild anything deleted, re-apply firewall policy, and remove unauthorized tokens or SSH keys.
5. Fix the cause. Replace the shared root login with named accounts, set token expiry, and move secrets into a managed store with rotation.
The ordering principle: stop the bleeding, then investigate, then repair, then prevent. Investigating first leaves the attacker's access live.
2. Grant the contractor deploy-only access. Explain what the platform's token and IAM model lets you restrict and what it does not, and name the compensating control you would add.
Read the worked answer
What is straightforward: creating a separate identity rather than sharing an existing credential, and issuing a token with an explicit expiry and only the permissions the task needs - compute read/write for deployment, no billing or account-level access, no volume destruction rights if the permission model separates them.
What is not: depending on your account's IAM configuration, permissions may attach to resource types account-wide rather than to individual instances, and some destructive operations can fall under the same write permission that deployment needs. Verify the current capability before promising "only these three instances."
Compensating controls:
- Short token expiry (weeks, not years) and rotation at offboarding.
- A dedicated tag or project convention on the instances the contractor may touch, plus alerting on create/delete operations outside it.
- Weekly audit-log review during the engagement.
- For cluster work, a namespace-scoped kubeconfig so RBAC - not the token - enforces the boundary.
Say plainly in the contract that access is time-boxed and logged.
3. Rewrite the firewall and SSH posture with specific rules.
Read the worked answer
Cloud Firewall (per role, not per instance):
- Public web instances: allow 80 and 443 from 0.0.0.0/0. Nothing else inbound.
- SSH: restrict port 22 to the office egress ranges and the CI runner's addresses, or remove public SSH entirely and reach hosts through a bastion host on a VLAN, or use a private-network-only admin path.
- Database and internal app tiers: deny all inbound from the internet; allow only the specific VLAN CIDR and port from the app tier.
- Default deny inbound with explicit allows, applied to groups of instances so new hosts inherit the right policy.
SSH:
- Disable password authentication and root login; require key-based auth only.
- Centralize keys by role and remove departed engineers' keys, which are the usual forgotten artifact.
- Keep a documented break-glass path so the rule survives an outage.
A firewall that allows 22 from anywhere is the item most likely to appear in a real compromise report, and it is free to fix.