In the brave new world of Cloud technology, corporate users are clamoring to get access to the cloud. Whether it is developers testing out new applications, seasoned DBAs building out databases to review performance, or IT professionals building VMs for the first time, everyone wants a piece of the pie. This can immediately raise questions about who should be allowed to build out infrastructure in the cloud and how to ensure these policies are enforced. . Without implementing tight controls, chaos and anarchy may prevail. In the internal IT environment, strict rules regarding who could build what and how they could build it were set in stone, but with the cloud many of those old ways of doing things are no longer applicable. This brings about headaches for granting access to the cloud and making sure that users build within the guidelines that IT has dictated.
How can an IT organization put some rules or policies in place to make sure that infrastructure is built out according to the standard that management wants? Enter the AWS Service Catalog. The AWS Service Catalog provides users with a predefined set of CloudFormation templates, called Products, curated by IT to guarantee that infrastructure is built out in a repeatable and defined process. Users that are given access to the AWS Service Catalog can deploy any Products that are defined within the Service Catalog Portfolio. This allows users to quickly deploy approved infrastructure all by themselves without having to involve IT. Users can do this because they are not given direct access to provision resources, rather each product within the AWS Service Catalog can be granted the proper permissions to deploy the predefined resources negating the need to provide your users any additional permissions. This will prevent your users from deploying infrastructure outside of the pre-defined IT infrastructure.
Service Catalog – under the hood
To see how the AWS Service Catalog and its dependencies are built and deployed, let’s review the AWS Service Catalog in more detail. To create an AWS Service Catalog for your users to consume, a Portfolio will need to be created in each region that you intend to use the AWS Service Catalog in. Each Portfolio will be deployed with its own unique Portfolio ID per region. Access is granted to the Portfolio through two defined IAM Roles for admins and users. IAM permissions for administering the Portfolio are granted through the IAM Role AWSServiceCatalogAdminFullAccess. Users that will be deploying the Products within the Portfolio will be granted access at a Portfolio level through the predefined IAM Role ServiceCatalogEndUserFullAccess. It is recommended to assign each IAM Role to a corresponding IAM Group, granting users in the group the permissions provided by the IAM Role.
Once the Portfolio has been setup and users granted access to view the dashboard, Products will need to be added for users to deploy services and infrastructure in each region. Similar to Portfolios, a Product ID is generated for each Product per region. Products are built from CloudFormation templates to allow for extremely granular control of what is provisioned. In addition, parameterization of each CloudFormation template allows for flexibility for deployments such as EC2 instance size, the number RDS instance you wish to deploy, or VPC design options at deployment time. Each Product is not limited to a single service either, multi-tier architectures with web servers, app servers, RDS instances and integrated lambda functions can be built out. Users are empowered to spin up complete environments with the click of a button, which allows for business agility while still enforcing security standards, utilization of AWS best practices, and cost containment..
An example of an AWS Service Catalog Product CloudFormation Template for DynamoDB.
AWSTemplateFormatVersion: 2010-09-09
Description: >-
DynamoDB_Table: This template demonstrates the creation of a DynamoDB table.
Parameters:
HashKeyElementName:
Description: HashType PrimaryKey Name
Type: String
AllowedPattern: ‘[a-zA-Z0-9]*’
MinLength: ‘1’
MaxLength: ‘2048’
ConstraintDescription: must contain only alphanumberic characters
HashKeyElementType:
Description: HashType PrimaryKey Type
Type: String
Default: S
AllowedPattern: ‘[S|N]’
MinLength: ‘1’
MaxLength: ‘1’
ConstraintDescription: must be either S or N
ReadCapacityUnits:
Description: Provisioned read throughput
Type: Number
Default: ‘5’
MinValue: ‘5’
MaxValue: ‘10000’
ConstraintDescription: must be between 5 and 10000
WriteCapacityUnits:
Description: Provisioned write throughput
Type: Number
Default: ’10’
MinValue: ‘5’
MaxValue: ‘10000’
ConstraintDescription: must be between 5 and 10000
Resources:
myDynamoDBTable:
Type: ‘AWS::DynamoDB::Table’
Properties:
AttributeDefinitions:
– AttributeName: !Ref HashKeyElementName
AttributeType: !Ref HashKeyElementType
KeySchema:
– AttributeName: !Ref HashKeyElementName
KeyType: HASH
ProvisionedThroughput:
ReadCapacityUnits: !Ref ReadCapacityUnits
WriteCapacityUnits: !Ref WriteCapacityUnits
Outputs:
TableName:
Value: !Ref myDynamoDBTable
Description: Table name of the newly created DynamoDB table
In order to allow for these resources to be built in AWS without providing the users direct access to the services, Products are given proper permissions to deploy the defined architecture. This is done through what are called Service Catalog Launch Constraints, which work in concert with IAM policies and roles to assume the proper permissions on behalf of the users. First, a policy must be defined detailing the exact permissions needed to build the infrastructure that makes up the Product. Once defined, the IAM Policy is assigned to an IAM Role. This IAM Role is then assigned to the Launch Constraint, allowing the Product to assume the IAM role and all its permissions in order to deploy the services on behalf of the user. Since IAM is a global service these Roles and Policies will only need to be defined once per AWS Account.
To ease the deployment of the AWS Service Catalog across multiple regions within your AWS account, AWS has created AWS CloudFormation Templates for the entire solution. From a single CloudFormation stack, IT can deploy multiple AWS Service Catalog Portfolios across regions with Products created from their own AWS CloudFormation Templates along with all the necessary IAM Roles, Polices, and Groups. An example of creating the Portfolio through CloudFormation is below:
Description: “This CF template creates the main Portfolio and outputs the PortfolioID.”
Resources:
MainPortfolio:
Type: “AWS::ServiceCatalog::Portfolio”
Properties:
AcceptLanguage: “en”
Description: “Main Portfolio.”
DisplayName: “Main Portfolio”
ProviderName: “Foghorn”
Outputs:
PortfolioID:
Value: !Ref MainPortfolio
The AWS Service Catalog is the perfect tool for allowing users within your organization the autonomy to create and destroy infrastructure and services at will without affecting the IT service pipeline while guaranteeing that a properly architected solution is deployed. Contact the us at Foghorn to help you deploy this solution to help dynamically improve the speed and effectiveness of the cloud for all users in your organization.
