Deploying Identity and Access Management (IAM) Infrastructure in the Cloud - PART 1: PLANNING
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)
Reference Architecture for Identity and Access Management (IAM) cloud deployment (select to expand)
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