On Akamai Cloud (formerly Linode), one Cloud Manager login or one personal access token can create, read or destroy every Linode, Kubernetes cluster and bucket in the account, so account and token hygiene matter more than any single server setting. The platform is popular with small teams and developers because it is simple, and the same simplicity means many accounts run with one shared admin user, full-access tokens with no expiry and Linodes reachable on every port. This guide is for engineers and security teams who run workloads on Akamai Cloud compute. It covers sign-in and two-factor authentication, the Identity and Access role model, personal access tokens and Object Storage keys, Lish console access, Cloud Firewall, Linode Kubernetes Engine (LKE) control plane access, the Metadata service and what the events and logins APIs let you monitor. Broader cloud principles are in the Cloud Security Guide.
This is an independent guide from NHI Mgmt Group, based on Akamai's public documentation as of November 2026. It is not sponsored or reviewed by Akamai. Product features change, so confirm settings against Akamai's current documentation.
Key takeaways
- Turn on 2FA and check where sign-in really happens. Accounts that sign in through Google, GitHub or Akamai Control Center SSO bypass Cloud Manager's own password and 2FA settings, so the strength of that external account is the strength of your cloud.
- Move users to Identity and Access roles. Akamai is migrating from the old grants model to roles such as account_admin and entity roles at viewer, contributor and admin level; give account_admin to very few people.
- Scope and expire every token. Personal access tokens carry an access level per product and an expiry chosen at creation, are shown once and should be one per application.
- Cloud Firewall is not on by default for everything. It attaches per Linode, interface or NodeBalancer, does not filter VLAN traffic, and NodeBalancer backends need their own firewall if exposed.
- Lock down LKE and Lish. Enable the control plane ACL (off by default) and set Lish to key authentication only.
How identity and access work in Akamai Cloud
Human access goes through Cloud Manager; programmatic access goes through the Linode API (v4) with personal access tokens or OAuth clients, and through separate access keys for Object Storage. Every user belongs to one account, and parent and child accounts exist for organisations that manage several.
| Sign-in route | Who controls password and 2FA | Security points |
|---|---|---|
| Cloud Manager username and password | Akamai Cloud | Enable 2FA (Akamai strongly recommends it); three security questions must be set first; if 2FA is off and the user has not signed in for 30 days, an emailed one-time code is required |
| Google or GitHub third-party authentication | The external provider | Enforce MFA in that provider; Lish over SSH must then use keys |
| Akamai Control Center single sign-on | Akamai Control Center | Cloud Manager password and 2FA are bypassed for the session; protect the Control Center account with a strong password and 2FA |
- Security questions are a recovery path: they are used when a user loses the 2FA device or recovery codes. Answers that can be researched (school, first car) weaken 2FA; store random answers in a password manager.
- Phone verification: required for accounts created on or after 27 June 2022 and used by Support to verify callers with an SMS code. Akamai warns never to pass on a code you did not request, which is the classic support-desk social engineering route.
- One user per person: Akamai advises a separate user per team member with only the permissions needed. Shared logins make 2FA, offboarding and the login history meaningless.
Admin roles and privileged access
Akamai documents an ongoing migration from the legacy grants model (unrestricted users, and restricted users with per-entity None, Read Only or Read-write) to Identity and Access, an RBAC model. Existing grants were mapped automatically to the closest roles, and the User and Grants tab is gone from Cloud Manager. The migration has no published end date, so check which model your account uses.
| Role or level | Scope | Typical holder | Guidance |
|---|---|---|---|
| account_admin | Full access to all entities and account settings | Two or three named platform owners | Equivalent to the old unrestricted user; 2FA mandatory; review monthly |
| account_linode_creator | Create Linodes only | Engineers who build servers | Pair with entity roles for what they then manage |
| account_billing_admin, account_billing_viewer | Billing | Finance | Keep finance users away from infrastructure roles |
| Default restricted roles | account_oauth_client_admin, account_event_viewer, account_notification_viewer, account_maintenance_viewer | Every restricted user | Note that restricted users can manage OAuth clients by default; review whether that is acceptable |
| Entity roles (*_viewer, *_contributor, *_admin) | A specific entity type, for example linode_viewer | Service teams | No role means no access; prefer viewer and contributor over admin |
- Do not mix models in automation: the API has parallel grants and Identity and Access endpoints, and Akamai warns against mixing them. Pick one in Terraform and scripts.
- Break-glass: keep one account_admin user with a hardware-backed second factor and sealed recovery codes, not used day to day.
- Offboarding: deleting a user removes Cloud Manager access, but check for tokens, OAuth clients, Object Storage keys, Lish SSH keys and SSH keys on Linodes the person created. See the Joiner-Mover-Leaver Guide.
Integrations, API tokens and service accounts
Akamai Cloud has four distinct non-human credential types to govern, each with its own scoping model.
| Credential | What it unlocks | Scoping available | Controls |
|---|---|---|---|
| Personal access token (PAT) | Linode API v4 as the user who created it | Access level per product; expiry chosen at creation | One per application, least access, vault storage, revoke when exposed or unused (T1528) |
| OAuth client | API access on behalf of users who authorise the app | OAuth scopes such as events:read_only or account:read_only | Inventory OAuth clients; restricted users can create them by default |
| Object Storage access key | S3-compatible access to buckets | Unlimited (all buckets in chosen regions) or limited (per bucket None, Read, Read/Write) | Prefer limited keys; type and permissions cannot be changed after creation, so create a new key and revoke the old |
| LKE kubeconfig | Kubernetes API of the cluster | Network restriction via control plane ACL | Treat as a cluster admin secret; do not commit it to repositories |
- Token ownership: PATs act as their creating user, so a PAT made by an account_admin is an account_admin credential. Create automation tokens from a dedicated restricted user with only the entity roles the pipeline needs, the closest thing the platform has to a service account. See the API Key Management Guide.
- Expiry: set an expiry on every PAT and track the dates; a never-expiring full-access token in a CI variable is the most common high-impact exposure. See How to set expiry policies on personal access tokens.
- Shown once: PAT values and Object Storage secret keys are displayed only at creation. Put them straight into a vault; do not paste them into tickets or chat.
- Limited keys and bucket policies: limited Object Storage keys are enforced through a bucket policy, so if you write your own policy, merge the existing one or limited keys start failing with HTTP 403. Bucket policies themselves require an unlimited key, which should then be held tightly (T1530).
- Delegate tokens: in parent and child account setups, delegate users on child accounts need a delegate user token for some operations; include those in the same inventory.
- Secrets on the server: keep tokens out of user data and StackScript-style bootstrap files. The Metadata service is reachable only from inside the Linode and Akamai states user data is encrypted, but any process on the instance that can read the user data can read secrets in it (T1552.005). Fetch secrets at boot from a vault instead.
Lish console access
Lish gives console access to a Linode even when SSH is broken, and Weblish needs the Linode's root password. Over SSH, users authenticate to a regional Lish gateway with their Cloud Manager password or with SSH keys added under LISH Console Settings.
- Set Authentication Mode to Allow key authentication only, which also matters because accounts using third-party authentication must use keys anyway.
- Verify the gateway's SSH host key fingerprint against Akamai's published list before accepting it.
- Remember that a Cloud Manager user with access to a Linode can reach its console; console access is a reason to keep entity roles narrow. See the SSH Key Management Guide.
Network controls: Cloud Firewall and LKE
Cloud Firewall is a stateful, network-based firewall available at no charge in all regions. It is applied per service, so new Linodes are not protected until you attach one (templates can help).
| Behaviour or limit | Value | Implication |
|---|---|---|
| Rules per firewall | 25, inbound and outbound combined | Group addresses into ranges; split by role rather than one giant firewall |
| Addresses per rule | 255 IPs or ranges | Enough for office and VPN egress lists |
| Ports per rule | 15 ports or ranges | Keep each rule to one service |
| Attachments | One firewall per service; one firewall can serve many services | Use a small set of standard firewalls (web, bastion, database) |
| NodeBalancers | Inbound rules only, on the public IP | Backend Linodes need their own firewall if they have public addresses |
| VLAN traffic | Not filtered | Use host firewalls or VPCs for east-west control |
| VPC with Linode Interfaces | Firewalls assigned per VPC and public interface | Review both interfaces, not only the public one |
| Object Storage | Not supported | Rely on keys and bucket policies |
- Default posture: build firewalls with inbound default drop, allow only the service ports from the needed sources, and restrict SSH (22) to a bastion or VPN range rather than 0.0.0.0/0 (T1021.004).
- Outbound: outbound rules apply to Linodes and Linode Interfaces; restrict egress on sensitive servers to slow data theft and command and control.
- LKE control plane ACL: disabled by default. When enabled, the control plane denies traffic except from allowed IPv4 and IPv6 CIDRs. It is per cluster, can be set at creation or later, and changes on an existing cluster can take up to 20 minutes. Add your own addresses first to avoid locking yourself out. For workload hardening inside the cluster, see the Kubernetes Security Guide.
Logging and detection
Akamai Cloud exposes account activity mainly through the API, so plan to pull it into your SIEM on a schedule.
| Source | Endpoint and scope | Lookback | Use it for |
|---|---|---|---|
| Account events | GET /v4/account/events, OAuth scope events:read_only, list_events permission | Last 90 days | Creation and deletion of Linodes, firewalls, users and tokens; filter with the X-Filter header |
| Account logins | GET /v4/account/logins, scope account:read_only, list_profile_logins permission | Last 90 days, successful logins for all users | Logins from unexpected countries or at unusual hours (T1078.004) |
| Host logs | Agent on each Linode | Your retention | SSH, sudo and application logs; not provided by the platform |
| Kubernetes audit and workload logs | Cluster tooling | Your retention | API activity in LKE clusters |
Because both APIs only look back 90 days, poll them at least daily with a read-only token and keep the records in your own store. Alert on new users, new or changed tokens and OAuth clients, firewall rule changes that open 0.0.0.0/0, and Linodes created in unused regions, which can indicate cryptomining with a stolen token.
Metrics
- 2FA coverage: percentage of Cloud Manager users with 2FA or MFA enforced by their external identity provider (target 100).
- Privileged users: number of account_admin users.
- Token hygiene: PATs without expiry, and PATs older than 90 days.
- Firewall coverage: Linodes and NodeBalancers with no Cloud Firewall attached, and rules allowing SSH from anywhere.
- Cluster exposure: LKE clusters without a control plane ACL.
Hardening baseline
- Account: enable 2FA for every user, set random security answers, verify the phone number, and confirm that Google, GitHub or Control Center accounts used for sign-in enforce MFA.
- Users and roles: list users, move each to the narrowest Identity and Access roles, keep account_admin to a few people plus one break-glass user, and remove shared logins.
- Tokens and keys: inventory PATs, OAuth clients and Object Storage keys; replace full-access or non-expiring tokens with scoped, expiring ones from dedicated automation users; convert unlimited storage keys to limited where possible.
- Network: create standard Cloud Firewalls with default drop inbound, attach one to every Linode and NodeBalancer, restrict SSH to bastion or VPN ranges, and add host firewalls for VLAN traffic.
- Kubernetes: enable the LKE control plane ACL for every cluster, after adding CI and admin addresses; store kubeconfig files in a vault.
- Console and bootstrap: set Lish to key authentication only; remove secrets from user data and bootstrap scripts.
- Monitoring: schedule daily collection of events and logins into the SIEM with a read-only token, and build the alerts above.
- Test and roll back: apply firewall and ACL changes to one non-production Linode or cluster first, keep the previous rule set exported, and revert by reattaching the old firewall if traffic breaks.
Common misconfigurations
- Single shared login: the whole team uses the account owner's credentials, often without 2FA, so one phished password owns everything.
- Full-access PAT in CI: a never-expiring token with read/write on all products sits in a pipeline variable or a public repository (T1552.001).
- No firewall attached: Linodes deployed from scripts with no Cloud Firewall, exposing databases and admin panels directly.
- NodeBalancer assumed to protect backends: backend Linodes keep public addresses with no firewall of their own.
- Open Kubernetes API: LKE clusters with the control plane ACL disabled and kubeconfig files on laptops and in repositories.
- Unlimited storage keys everywhere: every application gets an unlimited Object Storage key covering all buckets in the region.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|
| Users, 2FA and sign-in routes | IA-2, AC-2 | PR.AA-03 | 5.16 Identity management; 8.5 Secure authentication |
| Identity and Access roles | AC-3, AC-6 | PR.AA-05 | 8.2 Privileged access rights |
| Tokens and storage keys | IA-5 | PR.AA-03 | 5.17 Authentication information |
| Cloud Firewall and LKE ACL | SC-7 | PR.IR-01 | 8.20 Networks security |
| Events and logins collection | AU-6 | DE.CM-03 | 8.15 Logging; 8.16 Monitoring activities |
Practitioner checklist
- Enforce 2FA for every user, or MFA in the external provider for Google, GitHub and Control Center sign-in.
- Give each person their own user and the narrowest Identity and Access roles; keep account_admin minimal.
- Issue one scoped, expiring PAT per application from dedicated automation users, stored in a vault.
- Use limited Object Storage keys and rotate by creating new keys and revoking old ones.
- Attach a default-drop Cloud Firewall to every Linode and NodeBalancer, plus backends with public IPs.
- Enable the control plane ACL on every LKE cluster and treat kubeconfig files as secrets.
- Set Lish to key authentication only and keep secrets out of user data.
- Pull account events and logins into the SIEM daily, since the platform keeps only 90 days.
Standards and references
- Akamai TechDocs: Security controls for user accounts
- Akamai TechDocs: Migration from grants to Identity and Access
- Akamai TechDocs: Manage personal access tokens
- Akamai TechDocs: Cloud Firewall
- Akamai TechDocs: Control Plane ACLs
- Akamai TechDocs: Manage Object Storage access keys
- Akamai Linode API: List events
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Cloud Security Guide · API Key Management Guide · Kubernetes Security Guide · SSH Key Management Guide