Deploying Identity and Access Management (IAM) Infrastructure in the Cloud - PART 3: TOOLS, RESOURCES and AUTOMATION
Blog Series: Deploying Identity and Access Management (IAM) Infrastructure in the Cloud
Part 3: TOOLS, RESOURCES and AUTOMATION
In the previous installment of this four part series on “Building IAM Infrastructure in the Public Cloud,” we discussed core cloud infrastructure components and design concepts.
In this third installment, you move into the development stage, where you take your cloud infrastructure design and set up the objects and automation that will be used to implement it.
Deployment Automation Goals and Methodology
At this stage of deploying our infrastructure, you should have a functional design of the cloud infrastructure that, at minimum, includes:
AWS account in use
Region you are deploying into
VPC architectural layouts for all environments, including CIDR blocks, subnets, and availability zones
Connectivity requirements to the internet, peer VPCs, and on-prem data networks
Inventory of AWS compute resources used
List of other AWS services, how they are being used, and what objects need to be created
List and configuration of security groups and access control lists required
Clone of the Forgeops 6.5.2 repo from github
Deployment Objectives
The high-level objectives for proceeding with your deployment are as follows:
Create an S3 bucket to store Cloudformation templates
Build and execute Cloudformation templates to deploy the VPC hosting the lower environments and the production environment, their respective EKS console hosts, and additional EC2 resources as needed per your specific solution
Deploy EKS clusters from the EKS console hosts via the AWS CLI
Deploy EKS cluster nodes from the EKS console hosts via the AWS CLI
A Note on the Forgeops Repo
The Forgeops repo contains scripts and configuration files that serve as a starting point for modeling your deployment automation. It does not provide a turnkey solution for your specific environment or design and must be customized for your particular use case. Since this repo supports multiple cloud platforms, it is also important to distinguish the file naming conventions used for the cloud platform you are working with. In our scenario, “eks” either precedes or is a part of each filename that relates to deploying AWS VPCs and EKS clusters. Take some time to familiarize yourself with the resources in this repo.
Building the VPC Template
VPC templates will be created using AWS Cloudformation using your VPC architecture design and an inventory of VPC components as a guide. Components will typically include:
Internet gateway
Public and private facing subnets in each availability zone
NAT gateways
Routing tables and associated routes
Access control lists
Security groups, including the cluster control plane security groups
Private and or public jump box EC2 instances
EKS console instances
Additional ForgeRock related EC2 instances
S3 endpoints
Template Structure
While an extensive discussion on Cloudformation itself is beyond the scope of this text, a high level overview of some of the template sections will help get you oriented:
JSON formatted Cloudformation template; YAML format is also supported
The AWSTemplateFormatVersion section specifies the template version that the template conforms to.
The Description section provides a space to add a text string that describes the template.
The Metadata section contains objects that provide information about the template. For example this section can contain configuration information for how to present an interactive interface where users can review and select parameter values defined in the template.
The Parameters section is the place to define values to pass to your template at runtime. For example this can include values such as the name of your VPC, the CIDR block to use for it, keypairs to use for EC2, and virtually any other configurable value of EC2 resources that can be launched using Cloudformation.
The Mappings section is where you can create a mapping of keys and associated values that you can use to specify conditional parameter values, similar to a lookup table.
The Conditions section is where conditions can be defined that control whether certain resources are created or whether certain resource properties are assigned a value during stack creation or update.
The Resources section specifies the stack resources and their properties, like VPCs, subnets, routing tables, EC2 instances, etc.
The Outputs section describes the values that are returned whenever you view your stack's properties. For example, you can declare an output for an S3 bucket name which can then be retrieved from the AWS CLI.
Cloudformation Designer
AWS Cloudformation provides the option of using a graphical design tool called Cloudformation Designer that dynamically generates the JSON or YAML code associated with AWS resources. The tool utilizes a drag and drop interface along with an integrated JSON and YAML editor, and is an excellent way to get your templates started while creating graphical representations for your resources. Once you’ve added and arranged your resources to the template, you can download your template for more granular editing of the resource attributes, as well as add additional scripting to the other sections of the template.
High-level view of Non-Production VPC. Supports individual environments for Development, Testing and Performance Testing, as well as shared infrastructure resources
High-level view of Production VPC with a single Prod environment and infrastructure resources
Closer view of subnet objects. These are private subnets, and are arranged by availability zone. The two subnets on the left are in AZa, the two in the center are in AZb, and the two on the right are in AZc.
Closer view of one component in the template, which in this case is a security group that will be used during the deployment and operation of the EKS cluster for our Test environment. Note: the JSON code that defines this object in the bottom pane, and the visual connections that illustrate relationships to other objects.
The same object with code in YAML format
EKS Console Instances
The EKS console EC2 instances will be used to both deploy and manage the EKS clusters and cluster nodes after the VPC deployment itself has completed. Each environment and its respective cluster will have its own dedicated console instance.
Each console instance will host shell scripts that invoke the AWS CLI to create an EKS cluster, and launch a cloudformation script to deploy the worker nodes. The Forgeops repo contains sample scripts and configuration files that you can use as a starting point to build your own deployment automation. The eks-env.cfg file in particular provides a list of parameters for which values need to be provided. These parameters include, for example, the cluster name, which subnets the worker nodes should be deployed on, the number of worker nodes to create, the instance types and storage sizes of the worker nodes, the ID of the EKS Optimized Amazon Machine Image to use, etc. These values can be added manually after the VPC and the EKS console instance is created, or the VPC Cloudformation template can be leveraged to populate these values automatically during the VPC deployment.
Prerequisites
Your EKS console instances will require the following software to be installed before launching the installation scripts:
git, if you need to clone your scripts and config files from a git repo
Forgeops scripts can be used to install these prerequisites as well as additional utilities like helm, or you can prepare your own scripts.
To avoid the need for adding AWS IAM account access keys directly to the instance, it is recommended to utilize an IAM instance profile to provide the necessary rights to deploy and manage EKS and EC2 resources from the CLI.
A key pair will need to be created for use with the EKS worker nodes
A dedicated security group needs to be created for each EKS cluster
An EKS Service IAM Role needs to be created in IAM
Next Steps
In this third installment of “Building IAM Infrastructure in Public Cloud,” we’ve discussed building the automation necessary to deploy your AWS VPCs and EKS Clusters. In Part 4, we will move forward with deploying your VPCs, connecting them to other networks such as your on-prem network and / or peer VPCs, and finally deploy your EKS clusters.
CONTACT US for an introductory meeting with one of our networking experts, where we can apply this information to your unique system.