This three part series is an update and a continuation to Stone Door Group’s previous Quay and Clair blog posts. [Securing Containers with Red Hat Quay and Clair Part 1 & Part 2]
In this series we will explore the new process of deploying Red Hat Quay and Clair in a Red Hat Openshift 4.X cluster running on AWS public cloud. The steps to install Openshift 4.X are significantly different than the steps required to install Openshift 3.X. The business case for using Openshift, Quay and Clair have not changed.
Red Hat Quay container registry builds, stores, and distributes container images. Red Hat Quay provides the registry service that integrates with Clair, which scans the stored container images for security vulnerabilities. Together, these tools deliver unparalleled container image security. We will be using the images stored in Quay to launch containers in Openshift while Quay and Clair exist as containers running in the Openshift cluster. Running the Openshift cluster on the AWS Public cloud allows us to access our container images seamlessly from anywhere in the world without relying on expensive on-prem resources.
Just as important as providing access, restricting access is critical to our Openshift, Quay, and Clair deployments. As you will see in this series, just because you can access your container images from anywhere in the world, doesn’t mean that they are available to the entire world. AWS gives us the ability to restrict access to our Openshift cluster, Quay, and Clair.
Moving beyond the question of how we deploy these resources, we need to understand why we deploy these resources.
In any container based IT environment, a very important question that must be asked is this, “Where do you get your container images?”
According to Container Journal, unprotected layers in images — especially those built using open source components — can leave the door open for hackers to gain access and ultimately control of key functions.
One significant advantage of container use is portability, which has facilitated the creation and sharing of microservices. These stripped out application functions are fully capable of running on their own, or in conjunction via APIs with other microservices. Developers utilize containers to create and share microservice-based applications. This process has driven developer productivity and increased capacity to deliver more high quality features to users quickly and efficiently.
However, public repositories like DockerHub and GitHub offer unrestricted access to microservices and other software content. While this does allow developers to download and access quickly, the unrestricted access to public software repositories can lead to serious security concerns.
Gartner notes that container security is, in fact, among the top ten priorities for IT professionals, as developers increasingly depend on containers to push digital business capabilities rapidly through the development pipeline:
“Each of these containers must be screened for vulnerabilities and issues before being put into production. Container security must integrate with common developer tools and the CI/CD pipeline and be used with comprehensive APIs to support a variety of security tools.”
The solution is trusted container registries that offer CIOs the capacity to regulate the origin of container based software content. Tools that offer private container registries for software developers are crucial to properly secure containers and maintain development speed and volume. These trusted registries offer the capacity to limit where developers find their content, digitally sign the images they use, and scan images for vulnerabilities.
Series Overview
In part 1 of this series, we will prepare the resources required to install Openshift as a public cluster on the AWS Public cloud infrastructure including resources required to deploy Quay and Clair on that Openshift cluster. A similar set of steps could be used to deploy Openshift, Quay and Clair in the AWS Government cloud infrastructure but we will not be covering the details of working in AWS Gov cloud in this series. The steps listed in part 1 of the series are required to complete the steps in part 2 and part 3.
Part 2 of this series takes you through the steps required to install Openshift as a public cluster in AWS. A public Openshift cluster has internet accessible resources. Installing in AWS provides us the capability to lock down our Openshift environment to limit access to just the systems we specify. It is possible to install Openshift as a private cluster which is accessible only through a dedicated network connection inside AWS or from your corporate network. We will not be covering the steps or requirements for deploying a private cluster in this series.
Part 3 of the series takes you through the steps required to deploy Quay and Clair on the Openshift cluster installed in part 2 of the series.
Preparing resources required to deploy Openshift, Quay, and Clair on AWS
The following sections walk you through preparing resources in AWS to support an Openshift cluster running Quay and Clair. These steps will be done on a local workstation or laptop.
Some words and buttons are specific colors in the AWS WebUI. I have tried to mimic those colors in this blog series to make it easier to find what you are looking for in AWS.
AWS IAM Access Key
An AWS IAM Access key is required for some API calls in AWS. We will be creating an AWS IAM Access key to utilize an S3 storage bucket for the Quay deployment. Here are the steps to create the AWS IAM Access key:
Log into your AWS account.
In the upper left corner of the initial AWS web page, Click on the word “Services”.
Clicking on “Services” expands a list of the available AWS services for your account.
3. Scroll down to the “Security, Identity and Compliance” section and click on IAM
The IAM dashboard page will be displayed including a list of choices down the left side of the page.
4. In the list of choices, click “Users”
This will cause a list of users associated with your AWS account to be displayed in the pane on the right side of the web page.
5. Find your account in the list and click on it.
The right side pane will change to display information about your user account.
6. Record the value for “User ARN” listed near the top of the page. It should follow the format of: arn:aws:iam::123456789212:user/your-aws-username@your-domain.com.
The twelve numbers in the middle of the “User ARN” value (123456789212 in the example above) are your AWS account number. We will use the entire “User ARN” value in a later step when we set up the access policy for our S3 bucket.
7. Click on the “Security credentials” tab and scroll down to the “Access keys” section of the page.
8. Click on the “Create access key” button and record the Access key ID and the Secret access key.
This is the only time you will be able to record the Secret access key. It can not be recovered if you lose it.
AWS S3 Bucket
An AWS S3 storage bucket will be used to hold Quay and Clair data. Here are the steps to create the AWS S3 storage bucket:
In the upper left corner of the AWS web page, Click on the word “Services”.
That will list the available AWS services for your account.
2. Scroll down to the “Storage” section and click on S3.
3. In the Amazon S3 page, click on the “Create bucket” button.
4. Provide a name for your S3 bucket and select the region where you will be deploying the Openshift cluster, Quay and Clair.
Enable or disable Bucket Versioning, add any Tags, and enable or disable Default encryption for your bucket based on the requirements of your Quay and Clair deployment.
5. Click on the “Create bucket” button to create the S3 bucket.
When the bucket has been provisioned, it will appear in the list of Amazon S3 Buckets.
6. Click on the name of your new S3 bucket from the list
This will cause a new page to open for your new S3 bucket
7. Click on “Permissions” from the list of words across the upper part of the page.
8. Scroll down to the “Bucket policy” section of the page and click the “Edit” button.
10. Add the following entry as the Policy for your S3 bucket. Modify the entry to use the correct values for the “AWS” lines and the “Resource” lines.
Replace “AWS-account-ID:user/username” with the “User ARN” value you recorded from your AWS IAM account for both “AWS” lines. Replace “your-s3-bucket” with the correct name of the S3 bucket you just created for both “Resource” lines.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::AWS-account-ID:user/username" }, "Action": [ "s3:ListBucket", "s3:GetBucketLocation", "s3:ListBucketMultipartUploads", "s3:PutBucketCORS" ], "Resource": "arn:aws:s3:::your-s3-bucket" }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::AWS-account-ID:user/username" }, "Action": [ "s3:PutObject", "s3:GetObject", "s3:DeleteObject", "s3:ListMultipartUploadParts", "s3:AbortMultipartUpload"oc create secret tls custom-quay-ssl-bundle --key=ca-bundle.key --cert=ca-bundle.crt ], "Resource": "arn:aws:s3:::your-s3-bucket/*" } ]}
When you have finished entering and editing the line in the S3 bucket policy, click the “Save changes” button.
The S3 policy allows the Openshift cluster to create, list, and delete objects in the S3 bucket. Specifically for our case, it allows the Openshift cluster to add, list, and delete images in the Quay repository.
Conclusion
You have completed Part 1 of this series and have the required resources configured to deploy an Openshift cluster on AWS. With the completion of Part 1, the next step is to deploy the Openshift cluster with the required resources to support Quay and Clair. Read Part 2. And finally, in Part 3, you will walk through the steps required to deploy Quay Container Registry and the Clair security scanner in our Openshift Cluster running on AWS public cloud.
About the Author
Eric Archer is a Senior Red Hat Consultant for Stone Door Group, a Hybrid Cloud and DevOps consulting company that helps enterprises successfully complete digital transformation projects. Stone Door Group offers rapid adoption of Red Hat Hybrid Cloud technologies with their OpenShift Container Platform Accelerator. To speak to Eric, drop us a line at letsdothis@stonedoorgroup.com
About Stone Door Group
Stone Door Group is a Hybrid Cloud and DevOps consulting company that delivers successful digital transformation projects in the private and public sectors. Stone Door Group is a team of leading experts in Hybrid Cloud and DevOps technologies. To speak with Eric and our team, send us an email at letsdothis@stonedoorgroup.com.