Blog Series: Deploying Identity and Access Management (IAM) Infrastructure in the Cloud

In a 2018 blog post, we explored high-level concepts of implementing ForgeRock Identity and Access Management (IAM) in public cloud using Kubernetes and an infrastructure as code approach for the deployment. Since then, interest from our clients has increased substantially with respect to cloud-based deployments. They seek to leverage the benefits of public cloud as part of their initiative to modernize their Identity and Access Management (IAM) systems. 

Essential details to consider when using cloud-based technology infrastructure: 

• Planning (PART 1)

• Design (PART 2)

• Development (PART 3)

• Implementation (PART 4)

In this blog series, we focus on exploring each of these concepts in greater detail to help you achieve a successful deployment of ForgeRock Identity and Access Management (IAM) in the cloud. While we will be referencing AWS as our cloud provider, the overall concepts are similar across other cloud providers regardless of the differences in specific tools, services or methods associated with them.

Part 1: PLANNING

Organizational Considerations

Given the power and capabilities of cloud computing, it is theoretically possible to design and build much of the entire platform with minimal involvement from other groups within your organization; however, in many cases, and particularly with larger companies, this can lead to significant conflicts and delays when it is time to integrate your cloud infrastructure with the rest of the environment and put it into production. 

The particulars vary between organizations, but here are suggestions of who to consult during the planning phase: 

• Network Engineering team

• Server Engineering team

• Security Engineering team

• Governance / Risk Management / Compliance team(s) 

These discussions will help you identify resources and requirements that will be material to your design. 

For example, the Networking team will likely assign the IP address space used by your virtual private clouds and work with you to connect the VPCs with the rest of the networking environment.

The Server Engineering team may have various standards, like preferred operating systems and naming conventions, that need to be applied to your compute instances. 

The Security Engineering and Risk Management teams will likely have various requirements that your design needs to comply with as well. 

One or more of these teams can also help you to identify common infrastructure services, such as internal DNS and monitoring systems that may be required to be integrated with your cloud infrastructure. 

Finally, your organization might already utilize public cloud and have an existing relationship with one or more providers. This can potentially influence which cloud provider you choose to move forward with, and the internal team(s) involved should be able to assist you with properly establishing a provider account or environment for your initiative.

Infrastructure Design Goals

Despite the absence of having to build a physical data center, planning cloud-based technology infrastructure has many similar requirements. For example:

• Defining each environment needed for both production and lower environments

• Identifying the major infrastructure components and services required and properly scaling them to efficiently service workloads of each respective environment

• Designing a properly sized, highly available, fault tolerant network infrastructure to host these components and services

• Providing internet access

• Integrating with other corporate networks and services

• Implementing proper security practices

• Identifying and satisfying corporate requirements and standards as they relate to implementing technology infrastructure

• Leveraging appropriate deployment tools

• Controlling costs

Other important characteristics that should be considered early in the process include deciding if you will be deploying into a single region or multiple regions, and whether or not you plan to utilize a blue / green software deployment model for your production environment.  Both will have implications on your capacity and integration planning.

Security

Shared Responsibility Model

There are two primary aspects of cloud security:

• “Security of the Cloud”

• “Security in the Cloud”

Cloud providers like AWS are responsible for the former, and you as the customer are responsible for the latter. Simply stated, the cloud provider is responsible for the security and integrity of the underlying cloud services and infrastructure, and the customer is responsible for properly securing the objects and services deployed in the cloud. This is accomplished using tools and controls provided by the cloud service provider, applying operating system and application level patches, and even leveraging third party tools to further harden security. Furthermore, as a best practice, your architecture should limit direct internet exposure to the systems and services that need it to function. 

See AWS Shared Responsibility Model for more information.

Cloud Components and Services

Each function in the cloud architecture is dependent on a number of components and services, many of which are offered natively by the cloud provider. Keep in mind that specific implementations will vary and you can use alternatives for some functions if they are better fit for your organization. For example, for code collaboration and version control repositories, you can use AWS’s CodeCommit, or a third party solution like GitLab if you prefer. For deploying infrastructure using an “infrastructure as code” approach, you can use AWS’s Cloud formation, or alternatively Hashicorp’s Terraform. On the other hand, there are cloud provider components and services that must be utilized, like AWS’s VPC and EC2 services which provide networking and compute resources respectively. The following is a summary of some of the components and services we will be using. If you are relatively new to AWS, it would be helpful to familiarize yourself with them:

Amazon VPC

Provides the cloud based networking environment and connectivity to the internet and on-prem networks

Amazon EC2

Provides compute resources like virtual servers, load balancers, and autoscaling groups that run in the virtual private cloud

Amazon Elastic Kubernetes Service

Managed kubernetes service that creates the control plane and worker nodes

AWS Global Accelerator

Managed service for exposing applications to the internet

Amazon Route 53

Cloud based DNS service

Amazon Simple Storage Service

Object storage service

Amazon Elastic Container Registry

Managed Docker Container Registry

AWS CodeCommit

Managed source control service that hosts git-based repositories

AWS Certificate Manager

Service for managing public and private SSL/TLS certificates

AWS Cloudformation

Scripting environment for provisioning AWS cloud resources

AWS Identity and Access Management

Provides fine-grained access control to AWS resources

Amazon CloudWatch

Collects monitoring and operational data in the form of logs, metrics, and events.

AWS Support and Resource Limits

Support 

As you work through the design and testing process, you will invariably encounter issues that can be resolved more quickly if you have a paid AWS support plan in place that your team can utilize.

You can review the available support plans for more information to determine which plan is right for you. 

Resource Limits

While it is still early in the process to determine the number and types of cloud resources you will need, one aspect you will need to plan ahead for is managing resource limits. The initial limits that are granted to new AWS accounts for certain resource types can have thresholds that are far below what you will need to deploy in an enterprise environment.

Furthermore, the newer the account, the longer it can take for AWS to approve requests for limit increases, and this can adversely impact your development and deployment timelines. Establishing a relationship with an AWS account manager and familiarizing them with your initiative can help expedite the process of getting limit increases approved in a more timely fashion until the account has some time to build a satisfactory payment and utilization history.

Next Steps

We’ve covered several aspects of the planning process for building your IAM infrastructure in Public Cloud. In the second installment of this four part series, we will explore design concepts, including the architecture for the VPCs, EKS clusters and integration with on-prem networks.

For more content on deploying Identity and Access Management (IAM) in the cloud, check out our webinar series with ForgeRock: Containerized IAM on Amazon Web Services (AWS)

Part 1 - Overview

Part 2 - Deep Dive

Part 3 - Run and Operate