Are you currently experiencing an attack?

Are you currently experiencing an attack?

Securely Using Digital Ocean, Part 2

The major cloud providers use shared-responsibility models that require their customers to maintain strong security postures. And one of the key elements to securing cloud-based resources is robust access and authorization controls.

Continuing from Part 1 of this series, where we reviewed some basic similarities and differences with the Big Three, this article focuses on access and authorization. We’ll discuss Identity and Access Management (IAM) and how DigitalOcean compares to AWS, GCP, and Azure.

What Is IAM?

Identity and Access Management controls “who” has access to “what.” Most cloud IAM implementations are built on the foundation of Role Based Access Control (RBAC). For a given “identity,” which is typically a user or in some cases a non-interactive service or system, access and authorization are determined by assigning roles to that identity.

For example, a hypothetical software engineer could have a user account that is typically defined with some metadata like email address, name, office location, and other info. In a well-configured RBAC system, this account would have no access or authorizations “at rest.” However, the engineer could assume certain roles to receive these permissions. These roles may assign broad permissions in QA and development environments but very few, if any, in the production environment. The engineer could thus assume the relevant role and perform the necessary tasks, and then, after a fixed amount of time, the association would be terminated.

The ultimate goal of an IAM system is to implement the Principle of Least Privilege (PLOP). With PLOP, identities such as users only have the minimum or “least” amount of access required to successfully perform a task or action. In the event of an attack or compromise, PLOP helps limit the potential blast radius from the actions taken by a threat actor. Any elevated permissions will be explicitly limited in scope, hopefully minimizing the consequences and cost.

How DigitalOcean Measures Up to the Big Three

When comparing potential cloud providers, organizations thoroughly evaluate foundational services like compute and databases for performance, price efficiency, and overall suitability for a given use case. However, IAM is an implicit requirement when interacting with any cloud resource and forms an important and unique component of any platform, as a customer will need to use and manage that provider’s IAM implementation.

Unfortunately, DigitalOcean lacks a granular, well-defined IAM service such as AWS has; consequently, their user management centers around account management. The closest parallel structure to this is GCP’s service, as Digital Ocean’s hierarchy of teams, projects, and members is somewhat similar to how GCP ties in with Google’s account management.

With DigitalOcean’s account management, you can organize user identities via teams and resources under projects. You can then issue SSH keys and access tokens to these user accounts for accessing droplets and the API, respectively. Teams are where you define the logical separation between cost centers within an organization, ensuring resources under that team are billed separately from others while allowing team members to share access via a basic implementation of assigned roles. Projects, on the other hand, act as a high-level means of organizing resources; however, they do not provide much in the way of access or authorization controls beyond what the platform offers.

Some Drawbacks

DigitalOcean ultimately lags in its IAM capabilities when compared to the other providers. Some notable gaps include: no custom roles, no custom policy objects, and no instance/droplet profiles. The lack of custom roles and policy objects is particularly egregious in light of the need for fairly granular RBAC controls to implement a finely tuned PLOP policy. For example, there is no first-party method in DigitalOcean’s account management to limit team member access to resources shared within that team. Team members can only be restricted based on a set of three roles: Owner, Biller, and Member. Each role provides limitations on what resources can be read from or written to, but there is no way to define that some members can access Droplet A, but not Droplet B.

A possible implementation would be to have several teams created, each aligned to a given set of resources, but there exists no mechanism for cross-team role assumption, and there is an upper boundary on the number of teams a user can join.

While the IAM capabilities of DigitalOcean are obviously lacking, there are still ways to ensure that access and authorization are handled as securely as possible. The next section will look at some tips and potential methods to optimize DigitalOcean IAM to achieve just this.

Tips for Utilizing DigitalOcean IAM Securely

With a limited feature set, it appears that implementing an effective security posture for access and authorization is a tall mountain to climb when using DigitalOcean. While the story isn’t great compared to the other providers, there are still ways to provide some parity.

Use Two-Factor Authentication (2FA) Wherever Possible

DigitalOcean accounts support 2FA, and it should be enabled for all accounts and users. For any online access control, 2FA should be considered table stakes at this point. While the DigitalOcean implementation is limited to account login, most third-party providers offer APIs for implementing more granular, lower-level 2FA access. For example, 2FA could be used with bastion hosts to limit direct user access to certain droplets within a DigitalOcean team or project, without needing to rely on DigitalOcean’s internal account management.

Limit the Scope of Personal Access Tokens 

For API access, DigitalOcean allows you to generate personal access tokens. Unfortunately, the ability to control permissions is very limited, with only “read” and “write” scopes available. Ideally, tokens are scoped only for read whenever possible, with only a small subset of tokens having write access. DigitalOcean also does not provide much in the way of activity monitoring, so teams will need to pay close attention to the security history of a given account to validate past user behavior. Using a third-party logging tool to ingest actions data might also provide some additional insights and potentially alert engineers to anomalous behavior in a given account.

Maintain Small Team Sizes

Given the limitations of RBAC within DigitalOcean teams, it makes sense to limit their member count as much as possible for a given family of resources. Critical resources in high SLA environments, or those containing sensitive data, should only be accessible by a small subset of engineers and operations staff. Ideally, resources are deployed automatically via a mechanism like CI/CD and require no actual interactive access to manage. Users are given access to toolchains with a broader array of access and authorization controls for infrastructure management, enabling the shortcomings of the underlying platform to be abstracted away under a layer of middleware.

IAM: The Big Gap

IAM is unfortunately where DigitalOcean falls short compared to its competitors. Organizations will be forced to evaluate whether DigitalOcean offers enough features, performance, and competitive pricing to offset this gap. There are mitigations and third-party tools that can be implemented to augment Identity and Access Management in DigitalOcean, but it would still pale in comparison to a robust IAM offering like what AWS provides.

The third and final article in this series will evaluate how DigitalOcean compares across key service categories, like network, storage, and compute, and will offer tips on utilizing them securely.

Note: Reblaze provides comprehensive web security for Digital Ocean, and runs natively on this platform.

Get your price quote

Fill out your email below, and we will send you a price quote tailored to your needs

This website uses cookies to ensure you get the best experience on our website.