 Hi, my name is August Siminelli and I'm a technical marketing manager at Red Hat. And today I want to tell you about the new AWS controllers for Kubernetes feature for OpenShift and AWS. This is a new component of OpenShift which helps customers who are running clusters in AWS by allowing them to describe AWS resources from directly within their Kubernetes environments. So let's go ahead and look at a standard developer environment. We've got a developer working with an OpenShift deployment running in Amazon. The developer likes to code against the Kubernetes API to deploy an application. There may be services, deployments, anything out there to allow a customer to consume it. But what about when the developer wants to extend that into the Amazon space? They want to bring in AWS resources, S3, RDS, EC2, something like that. Then the developer has to use a different form. They can't go through the Kubernetes API and this can create some confusion. But of course there are ways to do it with Amazon. You might use the APIs, cloud formation, or the AWS web console. But the problem is you get into a state where there are multiple methods being used and it takes away from the efficiency of the developer. So what can we do to get around that? Introducing the Amazon controller for Kubernetes or AC. So what exactly is AC? Well, AC stands for AWS controllers for Kubernetes. With AC, you can take advantage of AWS managed services for your Kubernetes applications without needing to define resources outside of the cluster. AC provides a consistent and familiar Kubernetes interface for AWS by installing a custom controller, CRD, and RBAC for each AWS service. This means that instead of using the AWS web console or cloud formation, a developer can use the Kubernetes API to describe all the resources their application requires, including AWS resources. AWS controllers for Kubernetes are a collaborative upstream project with a multi-vendor community. There is extensive documentation and examples available online. And the code for the controllers is generated automatically from the AWS APIs, allowing for rapid and ever-growing support of AWS services. So as you can see, AC can take the place of the need to use those external methods, allowing the controller to directly manage the Amazon resources. This replaces the need for the developer to interact with Amazon and instead allow the Kubernetes API to control the controller, meaning the developer sees a consistent flow through OpenShift straight through to AWS. And here's the really good part. To get an AC controller into an OpenShift cluster and to hand over the AWS service management, you can use the operator lifecycle. What this means is you can use an operator to install each and every AC controller. It makes it super easy. Let's go ahead and take a look at the process to make this happen. First, we need to create an account in IAM for the AC operators. You can create this account in the web console, but I've chosen to do it using the AWS CLI. This account can be any username, as there's nothing in the operator or AWS that checks for a specific name. In this case, I'm using a default service account and will attach all policies to it, but you could create an account for each controller for finer control. We create an access key to allow for programmatic access. We'll need these values for later. Now it's time to attach the AWS policies to that user. This allows the controller to interact with the resources across AWS. Each service controller repository provides a recommended policy ARN for use with the controller. For this example, I'll be setting up an S3 operator and an ECR operator. With our AWS environment now set up, we need to create some assets in OpenShift to prepare for our operators. We create a dedicated project to keep things tidy, and then a config map to provide some environmental configuration. It contains information on how the controller should run, which region in AWS the resource should be created in, and which namespace to watch for requests. This is required beforehand by OLM and does not contain any IAM information. A secret is created containing the access keys for the account. The operator will reference this secret to access AWS. Now it's time to install the operators themselves. This follows the familiar procedure used for any operator. Visit operator hub, find the AWS operator you want, and install. But please do note, at this time the ACQ operators are community support only. When installing, you can choose the channel, the installation mode, the namespace, and the update strategy. For this demo, I'll install and demonstrate the S3 and ECR controllers. We'll speed up the video to show the process in its entirety. And now both operators are installed. So let's take a look at some of the resources created by the operator. We see the controllers running in their pods, one for each service. We see the controller's services, deployments, and replica sets. Each operator also installs a CRD for its AWS service. Diving into the CRD, we can see it offers quite a comprehensive spec, with a lot of options for interacting with the AWS service it represents. If we explain one of those available options, for instance the S3 bucket command, we can start to learn how to use the CRD. So let's go ahead and give this a try. We will now create an S3 bucket and an ECR repository using Kubernetes custom resources. First, let's use the AWS CLI to see what we have. We can see a single S3 bucket. It's our registry created as part of the Rosa install. And we don't have any ECR repositories. And here's a simple CR for an S3 bucket. As you can see, our CR is very simple. It's a great way to start. It creates a bucket with some tags and a specific name. So let's apply the CR and use the AWS CLI to check again. And there it is. We now have got an S3 bucket created entirely from a Kubernetes custom resource via the Kubernetes API. Now, the app controller manages this custom resource and therefore all the underlying AWS resources. So we can use OpenShift to query and manage the AWS resource via the Kubernetes API. Let's do the same for ECR. I've sped up the video slightly to show things in their entirety. You can also create custom resources via the UI. Let's take a look at the OpenShift developer view to see the ACK integration with the UI. Creating a new AWS resource from within OpenShift is pretty easy. The operator installs comprehensive and detailed forms that can be filled out to create the resources. Not only is it easy to use, but it's a great way to learn the options available in each CRD. Here we're going to create another S3 bucket and ECR repository via the GUI. I've sped up the video so you can view the process in its entirety. And of course, all these resources are visible in the AWS console. Here's our S3 buckets from both the UI and CLI create operations. And here are the ECR repositories we created. You can even see the one with the scan on push feature that we asked for in our CR. With AWS controllers for Kubernetes, you can more easily create AWS resources from inside your standard Kubernetes development flow. There are many controllers available today and more on the way. And with easy installation and management with OpenShift's operator lifecycle manager and operator hub, installing and managing controllers is an easy, familiar process. AWS controllers for Kubernetes are available today in the operator hub on your OpenShift environment. Have a look at the many AWS services available and start using them today. Thanks for watching.