In large AWS environments, you want to provide your users with secure and compliant ways to use AWS cloud services. You can empower them to consume services independently and reduce your operational teams‘ workloads. The result? Increased user satisfaction and more time for operations to concentrate on value-adding activities. AWS offers a native way to create and share your products in your AWS organization with the AWS Service Catalog.
Creating, managing, and controlling your organization's AWS Service Catalog products is the first step to providing self-service. Your organization benefits from a variety of advantages, including:
Each AWS product is based on an AWS CloudFormation template. The definition of what a product executes and, consequently, what a user can do, is determined in the template. It’s also possible to enable additional restrictions through various measures, called constraints:
Launch Constraints define which IAM role the AWS Service Catalog assumes when it launches the product
Notification Constraints give the possibility to get information via SNS (Simple Notification Service) when products are managed
Tag Update Constraints provides the ability to prevent tag updates on deployed resources
Stack Set Constraints enables StackSets deployments to multiple accounts or regions
Template Constraints limit the options for users at launch
As well as constraints, there are so-called ‘service actions’ which offer the possibility to perform predefined actions on already provisioned AWS Service Catalog products. (For example, initiate a restart of an EC2 machine). Service actions can be defined in AWS Systems Manager documents and attached to a product.
One of our enterprise customers needed a way to enable self-service capabilities to centrally managed and shared services. Furthermore, users are only allowed to use services that provide a minimum level of security. And this is where the AWS Service Catalog comes into play, as its capabilities can cover the requirements.As our customer also has high demands for automation, the entire solution had to be rolled out in an automated and reusable way. In this case, a CI/CD integration was essential.
During the implementation, we worked with our customers’ private GitLab repository and AWS CodePipeline, and CodeBuild. According to security requirements, the IAM permissions for the programmatic GitLab access to the AWS account are supposed to be as light as possible. For this reason, GitLab is only used as a repository that pushes the solution code to an S3 bucket in each of the customer's test and production accounts.
The above actions trigger the actual deployment of the AWS Service Catalog portfolio, including the products. Deployment is done automatically when new products are integrated into the AWS Service Catalog configuration or when an existing product is replaced with a new template.
The accounts in which the configuration of the AWS Service Catalog portfolios and products are rolled out are provided with a delegated AWS Service Catalog administrator permission. The permission enables the sharing of the products into the AWS Organization from the respective AWS Service Catalog accounts.
AWS Service Catalog in an enterprise AWS Organization in combination with Gitlab
If you want to provide your users a secure and compliant way to consume AWS cloud services, the AWS Service Catalog provides good capabilities. However, a possible weakness is an unavoidable interconnection with the AWS CloudFormation Service, which occasionally requires a workaround with custom resources to trigger a Lambda function. In that case, the AWS Service Catalog product is just a shell, and the actual automation logic is placed in a Lambda function.
