Are you currently experiencing an attack?

Are you currently experiencing an attack?

Cloud Identity and Authentication 101

Moving from an on-premise deployment to the cloud can be confusing. Before, there were servers: physical hardware in a location that you owned or controlled. After, there are many services running somewhere on a cloud provider, which are themselves accessing other services.

This creates a host of new security challenges. For on-premise infrastructure, the perimeter can be tightly controlled. In a cloud architecture, there are numerous cloud services and resources, which by their nature are meant to be broadly accessible. Nevertheless, access must be tightly restricted to users who are correctly identified and authenticated.

Clearly, identity authentication and access management is crucial for securing your cloud-based applications and resources. Fortunately, the major cloud providers all offer services to help with this.

In this article, we’ll discuss the basics of cloud authentication, the different categories of authentication types, and some basic examples of when each type is necessary. For each category, we’ll also list the relevant services and tools offered by the top-tier cloud providers: Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP).

For the purposes of this article, a resource is a computer system resource within a cloud that a user might need to access. This could be a service, application, database, storage, and so on; as we shall see, the same concepts apply to them all.

Basic Concepts

In a well-structured architecture, access to resources is tightly controlled, and relies upon some key principles.

  • A “user” is any entity which requires access to a resource. No distinction is made between a human user and other types of users (services, applications, etc.), or among access methods (a command submitted via a management console, an API request, command submitted via CLI, and so on). Access is controlled in the same way, and according to the same principles, for all users.
  • Role-based access control (RBAC) should be used if possible. Users are not directly granted permissions to access various resources. Instead, groups are defined with appropriate permissions, and then users are assigned to those groups. For example, system administrators are not directly granted administrator permissions; rather, they are assigned to an admin group which has those permissions.
  • Access to resources is denied by default, except for users/groups who have been specifically granted the appropriate permission.
  • Permissions are granular. For example, for cloud storage, there should be separate permissions for listing the available buckets, listing the objects inside buckets, reading data, and writing data.
  • The principle of least privilege should always be followed. Every user should only have access to the resources it requires to do its job, and no more. For example, a service should not have access to a database it doesn’t use, nor should it have write access when it only needs to read data.

Cloud Authentication Types

The items listed above are general security principles. When using the cloud, three specific situations occur.

  • Intra-cloud access: when one user (e.g., a cloud service) needs to access a resource within the same cloud.
  • Internal-to-external access: when a user inside your cloud requires access to a resource outside your cloud.
  • External-to-internal access: when a user outside your cloud requires access to a resource inside your cloud.

Each situation introduces unique authentication requirements, which are discussed below.

Intra-cloud access

It is common for a resource within a cloud to require access to another resource within that same cloud. For example, a web application might need to store and retrieve data from a backend database (such as Google’s Cloud SQL), or from cloud storage (such as AWS S3).

It is tempting to have minimal restrictions for intracloud activities. Indeed, when a service can only be accessed from inside the cloud, there are certain performance optimizations that can be made. For example, HTTP is often used for intracloud communications, rather than HTTPS; this saves the computational overhead of encryption and decryption.

However, it is still important to have appropriately restricted permissions, even within a cloud. The principle of least privilege should always apply. For example, if a service only needs, and is only granted, read access to an internal datastore, then it can never accidentally modify or delete data, even if it contains a bug that would otherwise cause it to do this. Another example: a database admin of one project shouldn’t be able to access databases of other projects.

RBAC is very useful in managing intracloud communication. A well-designed structure of roles, groups, and permissions can make it possible to administer and correctly control even a complex cloud network.

Cloud Provider Services for Intracloud Authentication

Internal-to-External Authentication

Frequently, a user inside your cloud will require access to a resource outside of your cloud. For example, you might have a web application that uses a third-party API. Or perhaps you are using a multi-cloud strategy, which means a service within one cloud will need to access a resource running on a different provider.

Whatever the situation, accessing an external resource almost always requires the use of access credentials (such as logins, API keys, and so on). This means that users need the ability to store these credentials securely.

In the past, organizations have done this in various ways, such as hard-coding them into an application, or storing them in a separate file (often in clear text!) Clearly, these practices are not ideal.

Today, the top-tier cloud providers offer services to securely store credentials. Credential storage is actually a subset of a much larger challenge, which is how to securely store secrets when using cloud architectures. For more information on this, see our article Keeping Secrets in the Cloud.

Cloud Provider Services for Internal-to-External Authentication

External-to-Internal Authentication

In this situation, an external user—one outside of the cloud—requires access to a resource inside the cloud. (Note that an “external” user does not necessarily mean “outside of your organization.”)

External access to a cloud resource is the most potentially dangerous type. It requires a zero-trust approach, and should be structured and administered carefully.

The “principle of least privilege” is vitally important here. Not only should the authentication determine the ability of a user to access a resource, it should also stringently limit the level of access required, and restrict whatever data is returned on a per-user basis.

Cloud providers solve this problem in two ways:

  • By providing a means of securely storing and administering user credentials. Often, this data is linked to the role-based access mechanism used for internal service access so that a service can run using different access permissions for different users.
  • By providing a means of supplying temporary credentials to an external user. This is useful in certain situations, e.g. when resources are made available to users for whom it doesn’t make sense to construct and maintain specific identities.

Cloud Provider Services for External-to-Internal Authentication

Managed Active Directory

A special case for authentication arises from Active Directory (AD). In the past, many companies based their on-premise infrastructure upon Microsoft’s AD. This can perform a variety of tasks, but a main function of AD is to manage user permissions.

Therefore, as the cloud became popular, there were already thousands of companies that stored all of their user accounts and permissions in AD. There was also a huge number of legacy systems that required AD to do their authentication work.

For this reason, cloud providers offer a managed AD service. Unsurprisingly, Microsoft Azure goes even further. It not only offers a managed version of AD but fully embraces AD as a core component for all of its identity and authentication purposes.

Cloud Provider Services for Managed Active Directory


Understanding identity and authentication in the cloud might seem like an enormous task at first, especially because of the numerous services offered by cloud providers today. But when you break it down into the basics, there are four core cases to consider for cloud-native applications (three if you exclude the special case of AD). The cloud providers offer services (such as GCP security) for all four cases, and they work well when used correctly.

For more information on secure usage of the major cloud providers, see our article series on each one:

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.