DigitalOcean Security Guide: Teams, API Tokens, Spaces and Droplets

On DigitalOcean, a single full-access API token or Spaces key usually controls an entire team's infrastructure, and in small companies those credentials tend to live in laptops, CI variables and Terraform state long after the person who created them has moved on. DigitalOcean is popular with startups and product teams because it is simple, but that simplicity means fewer guard rails than the large hyperscalers provide by default. This guide covers how identity and access work in DigitalOcean teams, how to scope personal access tokens and Spaces keys, how to harden Droplets and storage, what logging exists and where it stops, and how the CIS DigitalOcean benchmarks fit. It is written for engineers and security leads who own a DigitalOcean account, often without a dedicated cloud security team.

Key takeaways

• Tokens are the real perimeter. Personal access tokens are bearer credentials; a Full Access token is equivalent to every API scope, including scopes for endpoints added later.
• Use Custom Scopes and expiry by default. DigitalOcean supports resource:action scopes such as droplet:create and a chosen expiry, and scopes cannot be edited later, so design them at creation.
• Spaces keys should be Limited access. Limited keys grant Read or Read/Write/Delete on selected buckets only; Full access keys can create, reconfigure and list every bucket.
• Enforce SSO or secure sign-in for every member. OIDC SSO with "Require sign-in via SSO only" moves joiner, mover and leaver control to your identity provider.
• Logging is thin, so plan for it. Team Security History shows actions with user and IP, but there is no documented export or API, and Spaces access logs are off by default.

How identity and access work in DigitalOcean

DigitalOcean organises resources into teams. Each team has its own members, resources, API tokens and, unless it belongs to an organisation, its own billing. Every member holds a role that determines their permissions over the team's shared resources, billing information and settings. DigitalOcean provides six predefined roles it manages, and you can create custom roles containing only the permissions you choose. Team owners have the widest control, including team settings and contact emails.

The token model has one subtlety worth knowing. If an owner expands a member's role, existing Custom Scopes tokens keep their original scopes, while Read Only and Full Access tokens reflect the new permissions. If an owner restricts a role, those permissions are removed from the member's existing tokens. Role changes therefore flow into tokens, which is useful when demoting someone, but an alias-scoped token silently grows when a role grows.

Admin roles and privileged access

• Limit owners: keep owner-level access to two or three named people. Owners control team settings, security settings and billing, and can change everyone else's role.
• Build custom roles: for engineers who only deploy applications or manage databases, create custom roles with just those permissions rather than granting a broad predefined role.
• Enforce secure sign-in: the team security setting requires every member to sign in with two-factor authentication, Google SSO or GitHub SSO. This is the minimum for any team with production resources. See the MFA Guide.
• Prefer OIDC SSO: DigitalOcean supports single sign-on with an OIDC identity provider (it does not document SAML). The IdP must serve its endpoints over HTTPS with a publicly trusted certificate. Roles are passed in a team_role claim, mapped from IdP groups (for example an Okta group prefixed DO:), and the role names must match DigitalOcean's role names.
• Enforce SSO only after testing: enable "Require sign-in via SSO only" once a test user has signed in successfully; DigitalOcean's documentation stresses leaving it off while testing because enforcement blocks email and password sign-in.
• Plan break-glass: the documentation does not describe a break-glass path when SSO is enforced. Before enforcing, confirm with DigitalOcean support how owners recover access if the IdP is unavailable, and record the procedure.

Small teams that do not run an IdP should at least enforce secure sign-in with 2FA and review membership monthly. Once you have an IdP for other SaaS, moving DigitalOcean to OIDC SSO means offboarding in one place removes Control Panel access. It does not revoke the tokens that person created, which is the next problem. See the Identity Provider and SSO Security Guide.

Integrations, API tokens and service accounts

DigitalOcean has no separate service account object: automation authenticates with a personal access token created by a team member, in that member's name and limited by that member's role. Treat every token used by a pipeline or tool as a non-human identity with an owner, a purpose, a scope and an expiry.

• Watch sensitive scopes: kubernetes:access_cluster lets the holder download cluster credentials, while kubernetes:read does not. spaces_key:create_credentials lets the holder create a Spaces key and view its secret, so it can mint storage access. Some resources also have an admin action, such as droplet:admin.
• Set expiry on every token: once expired a token stops authenticating and disappears from the account. Align expiry with your rotation process rather than choosing "never".
• Remember scopes are fixed: you cannot edit a token's scopes after creation; you can rename or regenerate it. Changing scope means a new token and a coordinated rotation.
• Store tokens as secrets: DigitalOcean's own guidance is that tokens "function like passwords" and belong in environment variables, not code. In practice, put them in a secrets manager or the CI platform's encrypted secrets, never in Terraform variables files committed to Git. See the Terraform and IaC Pipeline Credential Security Guide.
• Use a dedicated automation member if you need continuity: because tokens belong to a member, a pipeline token disappears in effect when its creator's access is restricted or removed. Some teams create a dedicated, SSO-governed automation account that owns pipeline tokens; document who controls it.
• Offboard tokens, not just people: when someone leaves, list and delete their tokens and rotate any Spaces keys they could have viewed. See the NHI Offboarding and Decommissioning Guide.

Leaked cloud tokens in public repositories remain valid until someone revokes them: the GitLab public repositories secrets study found more than 17,000 live credentials, the oldest committed in 2009. Scan your own repositories and CI logs for DigitalOcean tokens and Spaces keys. See the Git Secret Scanning Guide.

Spaces object storage

• Limited access keys: grant Read or Read/Write/Delete on named buckets. Full access keys can call all supported S3 APIs on all buckets, including creating buckets, changing lifecycle rules, bucket policies, versioning, CORS and static website settings, and listing every bucket.
• Policy interaction: limited access keys are incompatible with PutBucketPolicy bucket policies. You cannot create a limited key for a bucket with such a policy, or apply the policy to a bucket that already has one. Decide per bucket which model you use.
• Key handling: the secret is shown once, keys are managed only in the Control Panel (not the API or CLI) and the default limit is 200 keys per account, which makes manual inventory feasible and worth doing quarterly.
• Object privacy: files are private by default. Public ACLs make a file visible to anyone on the internet; review any bucket that serves public content separately from buckets holding data. Presigned links from the Control Panel's Quick Share last up to 7 days.
• Access logs: disabled by default. When enabled they must be written to a different bucket, follow the Amazon S3 server access log format and typically arrive within an hour.

Droplets

• SSH keys, not passwords: DigitalOcean recommends SSH key pairs over password logins. Upload team keys per person, remove leavers' keys from both the team and the authorized_keys files on running Droplets, and harden sshd. See the SSH Key Management Guide and the OpenSSH Server Hardening Guide.
• Cloud Firewalls: stateful, network-based firewalls that block any traffic not expressly permitted. Since August 2026 they support deny rules, which take precedence over matching allow rules. Apply them by tag so new Droplets inherit them, and restrict SSH to known addresses or a bastion.
• VPC networking: place databases and internal services on private VPC addresses; private Droplets have no public interface at all.
• Metadata and user data: the metadata service at 169.254.169.254/metadata/v1/ returns user data, vendor data, public keys and tags to anything on the Droplet that can make an HTTP request. DigitalOcean's page does not describe a session-token requirement, so do not put secrets in user data, and treat server-side request forgery in hosted applications as a path to it. See the Cloud Instance Metadata Services Compared Guide.
• Agents: the metrics agent is enabled by default at creation; the separate Droplet agent enables the browser-based Droplet Console. Decide deliberately whether console access is allowed for production.

Logging and detection

Because API calls made with a token are not exposed as a streamable audit log, detection depends on watching for effects: new Droplets, new tokens, new Spaces keys, firewall changes and unexpected spend. Billing alerts are a crude but effective signal for cryptomining after token theft.

Metrics

• Percentage of members signing in through SSO or secure sign-in (target: 100%).
• Number of Full Access tokens in use and the oldest token's age.
• Percentage of tokens with an expiry date and with Custom Scopes.
• Number of Full access Spaces keys and of buckets without access logs.
• Droplets without a Cloud Firewall tag or with SSH open to the internet.

Hardening baseline

CIS publishes two community-consensus benchmarks for the platform: CIS DigitalOcean Foundations Benchmark and CIS DigitalOcean Services Benchmark, both at version 1.0.1 at the time of writing. Use them as the audit checklist and the steps below as the rollout order.

1. Inventory: list team members and roles, every personal access token (owner, scope, expiry), every Spaces key, every SSH key and every Droplet without a firewall.
2. Lock down sign-in: enforce secure sign-in, then pilot OIDC SSO with one test user, then enable SSO-only once break-glass is agreed.
3. Replace broad credentials: issue Custom Scopes tokens with expiry for each integration, switch applications to Limited access Spaces keys, then delete the old credentials. Roll back by keeping the old credential for a short, recorded overlap window before deletion.
4. Network: apply tag-based Cloud Firewalls, move internal services to VPC addresses and close public SSH.
5. Logging: enable Spaces access logs, forward Droplet logs, set billing alerts and schedule a weekly Security History review.
6. Measure: review CSPM findings and CIS benchmark results quarterly and track the metrics above.

Common misconfigurations

• Full Access token in CI: one leaked pipeline variable gives an attacker the whole team, including creating Spaces keys and downloading Kubernetes credentials.
• Tokens tied to a departed engineer: pipelines break or, worse, keep working on a token nobody owns. Assign every automation token to a named owner and record it.
• Full access Spaces key in an application: a compromised web app can list and empty every bucket, not just its own.
• Public objects in a data bucket: mixing public assets with private data invites ACL mistakes; separate the buckets.
• Secrets in user data: any process on the Droplet, or an SSRF bug, can read them from the metadata service.
• SSO enforced with no recovery path: an IdP outage or misconfigured team_role claim locks everyone out.

Framework mapping

Practitioner checklist

• Enforce secure sign-in for every team member, then move to OIDC SSO with SSO-only enforcement.
• Keep owners to a small named group and use custom roles for everyone else.
• Replace Full Access tokens in automation with Custom Scopes tokens that expire.
• Record an owner, purpose, scope and expiry for every token and Spaces key.
• Switch applications to Limited access Spaces keys scoped to their own buckets.
• Enable Spaces access logs on every bucket holding data.
• Apply tag-based Cloud Firewalls and close public SSH on all Droplets.
• Keep secrets out of Droplet user data.
• Review Security History weekly and set billing alerts.
• Audit against the CIS DigitalOcean Foundations and Services benchmarks each quarter.

Standards and references

• DigitalOcean: How to Create a Personal Access Token
• DigitalOcean: API Token Scopes
• DigitalOcean: Configure Single Sign-On for Teams
• DigitalOcean: Manage Access to Spaces
• DigitalOcean: Spaces Access Logs
• DigitalOcean: Cloud Firewalls
• DigitalOcean: View Team Security History
• CIS: DigitalOcean Benchmarks

Related NHI Mgmt Group resources: Startup Identity and Secrets Security Guide · API Key Management Guide · Cloud Access Key Leak Playbook · CIS Cloud Foundations Benchmarks Guide · Cloud Security Guide