 Hello, everyone. Today, we will be talking about how to manage the provisioning and configuration of Kubernetes clusters using the cutting-edge GitOps approach. My name is Prasidha Satye and I am Principal Container Specialist at AWS. With me, I have Valentin Widmer, who is Cloud Infrastructure Architect at AWS. Today, enterprises running Kubernetes in production face a struggle between flexibility and complexity. So over the last few years, Kubernetes have given the developers more power and freedom, but now there's a chain scene in this evolving landscape. And the reason is, operations teams are facing difficulties managing the request from various teams in the organization. And this shift means imposing guardrails, golden path and standardized configuration to make things smoother. Many companies now use a platform engineering model. This means they have a special team of engineers taking care of several Kubernetes clusters and essential software for like observability, security and automation. So in large enterprises, there is a push for cell service, allowing the teams to request Kubernetes clusters. Tools like Terraform or Crossplane help in provisioning these clusters, but the configuration around the GitOps tools for deploying Kubernetes resources or applications becomes a critical task. And when these configurations are done manually, it often amplifies the operational overhead for the platform team, slowing down the developer's productivity as they wait for the access to these clusters. So addressing the operational overhead involves simplifying and streamlining the onboarding process for new teams onto the GitOps platform. And this requires a strategic approach to workload management, enabling the provisioning of multiple workloads at scale. It also requires configuration management best practices that automate the lifecycle of configurations and upgrades from a centralized source of truth. So let's dive into the solution that we are proposing to solve these challenges. Okay, before I start, I want to briefly introduce a few CNCF open source project that we are using in this solution design. Crossplane enables you to provision, compose and consume infrastructure in any cloud service provider using the Kubernetes API. Argo CD is a tool to implement the GitOps in your Kubernetes cluster administration. Argo workflow is an open source workflow engine for orchestrating your CI CD jobs on Kubernetes. And Argo event is a framework for automating workflows in Kubernetes. Now let's talk about this solution. Here on the left hand side, we have an AWS account which is owned by the platform engineering team in this company. And this organization also has one or more product teams who are application developers building their services. And their goal is to host their application on Kubernetes or EKS cluster deployed over the GitOps approach using Argo CD. In the demo that Valentin will show later, we'll see how this product team can automatically request a new EKS cluster and then get direct access to this cluster over the centralized Argo CD platform. Centralized Argo CD means you have one management cluster and this management cluster has an Argo CD instance and multiple teams are using the same Argo CD instance to manage the application inside their own clusters. And these clusters can leave outside of this management account and they can leave it on their own AWS account or they can also live on different cloud. So platform team here provides the management cluster and has Argo CD and crossplane installed. And then if a team wants to create a Kubernetes cluster or EKS cluster, they first interact with the management repository which is hosted in code commit. And in this repository, they have the crossplane claim to create a new EKS cluster. When this team pushes this claim into this management repository, Argo CD picks it up and then the crossplane creates the cluster inside another AWS account owned by the product team. Now the Argo event running inside this Kubernetes cluster is listening for the state of this crossplane claim. And once the crossplane has provisioned this cluster, then the Argo event will trigger the Argo workflow, which is just a sequence of steps to auto configure this Argo CD for this newly created cluster. We'll talk about this workflow in the next slide. So once this workflow has been completed, you can see in the step five, the product engineer who is basically part of this product team cannot directly interact with the freshly created repository. And this repository is connected to the Argo CD, which is central Argo CD and this Argo CD is connected to the newly created EKS cluster, which is in the product team VPC or in the product team account. Now they can start deploying their applications or their infrastructure components over the GitOps way. Now let's talk about what happens in this workflow. First, there is an API call to Argo CD in order to register the new cluster. Because Argo CD needs to have access to this new cluster, which is created inside the AWS another AWS account, Argo CD will create a service account inside the other cluster. And this service account has the permissions to access all the Kubernetes artifacts inside that new cluster. And these credentials from this service account will then be registered in this Argo CD. So this step basically is to enable Argo CD to reach the new EKS cluster or Kubernetes cluster that we just created and to have all the permissions to deploy applications or services into it. And then the next step is creating this OpenID Connect group and then add the users that were submitted when the product team created a new cluster to this group. So basically, there is a dedicated OpenID Connect group, which has some users of the product team and this group will now be allowed to manage the new EKS or Kubernetes cluster. Now step three is creating a dedicated repository in code commit and connect this repository with Argo CD because the product team wants to push their manifest into this repository. And then the manifest in this repository will be used by the centralized Argo CD to deploy in the GitOps mechanism to the new EKS or Kubernetes cluster. So we create a code commit repository using the AWS API. We retrieve the Git credentials and then we register the Git credential inside the Argo CD so that Argo CD has read access to this repository. And now in the step four, we grant OpenID Connect group which we created before and access to the Argo CD and the new cluster. We are using Cognito here and because Cognito supports OpenID Connect and Argo CD also supports OpenID Connect. So basically that means the users which are part of the group can access the Argo CD UI over the OpenID Connect. And it also makes sure that the users who have access to the repository can have access to their cluster. So as mentioned at the beginning, we are using a centralized Argo CD, which is also a multi-tenant Argo CD. So multiple product teams will be using the same Argo CD, right? And therefore we may need to make sure that only the product team sees its own resources and they cannot access other product team resources or clusters and so on. And then the last step is to bootstrap the new repository. Basically, we could deploy something like flow and bid, something like a secret operator or any additional management components. And once the workflow has been completed, then the product team can just go to the Argo CD URL and they can log in and start managing their applications in their cluster. With that, now I will hand it over to Valentin for the remaining session and the demo. Thanks, Prasida. Let's jump into the source code and start with the event source. The event source captures the cluster creation event in the form of a config map. The config map contains all of the metadata which describes the new cluster and is required as an input for the Argo workflow. This config map is deployed as part of the cross-plane composition. Next, we have the Argo workflow. The Argo workflow is split into four distinct steps. First, we start on line number 40 with the register cluster in Argo CD step. This step, as the name suggests, is there to register the new cluster so that Argo CD can manage applications within the cluster. Next, we have the configure user access. This sets up a group and adds the corresponding user within our IDP. For the demo, we are using Amazon Cogniton. Third, we have to grant access to Argo CD. This step allows Argo CD to create a project which is binds to this group that we have created in the previous step. With this step, we allow the multi tenancy so that multiple product teams can use our central Argo CD platform. And finally, we bootstrap the product team repo. This can contain various steps. In our demo, we just deploy a simple application, but you can think of additional applications like Fluentbit and other cluster management applications. Here we are looking into the register cluster in Argo CD task. This task defines an image, which is called register cluster. And this image contains the tools that we need in order to execute this specific step of the workflow. In our case, this is just the AWS CLI and the Argo CD CLI. Starting from line three, how the ten, the workflow script is executed. First of all, we retrieve the cube convict from the cluster which has been provisioned by crossplane. Then we log into Argo CD and finally we add the cluster to the new platform. The other steps are similar, but just with another logic. Let's jump into a demo to see the whole solution in action. First of all, we go into the management repository within code commit. Here we can see all the components which are deployed into the management cluster. This is mainly crossplane, Argo events and Argo workflows. Next, we switch over to Amazon Cognito, which acts as our IDP. Here we have a couple of uses configured. Then we have the group which allows us to manage the central Argo CD instance. And also we have wired up Argo CD with Cognito in order to allow login over OpenID Connect. The Argo workflows UI is empty as there are no workflows in the cluster. Here we have an overview about the applications deployed into the central Argo CD instance. For the settings part of Argo CD, we first see the repositories, which is the management cluster repository seen in the previous step. For the clusters, we only have access to the cluster itself where Argo CD is deployed. And projects which are used for multi-tenancy, we only have the default project. For the user info, this is the user that we are currently logged in and this user is part of the cluster events group, which is defined inside Cognito. Now let's switch to the console to have an overview about the crossplane composition, which allows product teams to create new EKS clusters. This EKS cluster composition allows product teams to create new EKS clusters and exposes a simple API. The simple API allows the product teams to customize the cluster creation by defining some networking parameters, but also, for example, the Cognitos version and the cluster name. Next, let's trigger our execution of a cluster creation event. First, let's have a look at the config map with all the metadata, which describes the new cluster. Like the cluster name, the account where the cluster has been provisioned, the name of the product team, and also the users which should be part of this product team. Now we are triggering the creation of this config map, which simulates the execution of a cluster creation. If we switch to Argo workflows, we can see one of the Argo workflow has been triggered. The Argo workflows certain steps are running in parallel in order to speed up the execution. The whole workflow should take roughly one minutes to execute. Now let's switch back to the AWS account to have a look at the repositories. The workflow have created a new repository dedicated for product team A and bootstrap it with certain applications. Here we just have the secrets application, but you can think of to extend that with a custom bootstrapping with other applications. Having a look at the Amazon Cognito user pool, we can see that we have a new group registered with the users specified within the config map. Now let's go over to Argo CD and check the settings. The newly created repository for product team A has been successfully linked to our central Argo CD instance. The same is true for the cluster. The cluster which has been provisioned in the cross account is now connected to Argo CD. And finally to achieve all the tenancy, we have a product team A project which limits the actions that the users of the new group can do within Argo CD. And also we have a product team A bootstrap application which is used by Argo CD to bootstrap the applications. Now let's log in as a user of the product team A repository. Here we have the K foo user which has been authenticated successfully and also it's part of the group of product team A. We also have one of the application previously explored within the repository of product team A. Important is also that the product team A does only have access to its own tenant. This brings us to the end of the presentation. What we're going to do is we're going to release the whole source code and the setup of the demo on GitHub. You can find it later this year in the AWS samples GitHub repository. Should you have any questions feel free to reach out to us. The best way to reach us is over email over emails addresses that you can see here on the screen. Thanks a lot for joining and we are looking forward to how you're going to extend the workflow for your organization.