Security, Identity, and Access
Identity and authorization
An Akamai Cloud account has a root or account-owner identity that should be reserved for billing and account-level changes. Day-to-day work should use additional users with roles and resource-level grants, so a user can be limited to specific instances, volumes, or NodeBalancers. API tokens are the programmatic credential: they are created with scopes such as read-only or read-write and an expiry, and the secret is displayed once. Two-factor authentication and SSH key pairs round out account and host access.
Network and data protection
Cloud Firewalls are stateful: you define inbound and outbound rules, traffic that matches no rule is denied inbound by default, and established sessions are tracked automatically. VLANs provide isolation between tiers, and private IPs are not routable from the internet. Akamai encrypts stored data at the platform level, and TLS termination can happen at a NodeBalancer or at Akamai's edge. Platform-level DDoS mitigation and a web application firewall at the edge add protection against volumetric and application-layer attacks.
Traps to watch
- A token can never do more than the user who created it: effective permission is the intersection of the token's scopes and the user's grants.
- A token secret cannot be retrieved later; if it leaks or is lost, revoke and recreate.
- Firewall rules bound to an instance do nothing for a volume or a VLAN; there is no separate security-group object hanging off a VLAN.
- Automation run with root credentials is an anti-pattern, and questions that praise it are wrong.
Rule of thumb
One token per integration, scoped to the smallest resource set and shortest practical expiry, read-only where the integration only reads, rotated on a schedule, and owned by a dedicated service user rather than a human's account.