Hello everyone. I am a security software engineer from Alibaba Cloud Container service team. My name is Kuang Da Hu. Today I'm glad to show you the security solution on ACK. This is the agenda of the slides. The first part is about why Container needs security more. In the second part, we will introduce, 'what is the security architecture design on ACK?', then we will show the key security feature illustration. Let me show some demo. Why we need the Container Security? Based on the state of Container, and Kubernetes security report from, [inaudible] this year, in the past three years, there is more and more enterprises using Container technology in their production environment. We can see the security is the biggest concern in companies Container strategy. In the same time, the threat is everywhere. According to the statistics, there is more than 25 [inaudible] vulnerabilities explored in the past three years. Based on the huge challenge, and the customer requirements, in this part, let me introduce our solution architecture design. Based on the huge challenge, we propose our higher-level security architecture. In the basic infrastructure Security layer, we have the solid securities feature provided from our private, and the public Cloud platform. Based on that, we implement RAM Integration Authentication and the RBAC authorization, and the auditing for Kubernetes API server and the IaaS resource. Also, we provide an open source solution called [inaudible] RAM was a fine-grain RAM role in workload pod. In software supply chain layer, we support image signing, scanning, and the security distribution during we workload building and deploying. In the Runtime security layer, we have signed back the Container which provides an independent kernel to enable enhancement of security isolation. Also, we support runtime mounting, and defense. This page is the component diagram of our security framework. We have access control, network security, and the SSL certificate service in our infrastructure platform, and the Integrated RAM, and the third-party SSR solution for authentication. There is a whole fine-grain [inaudible] authorization access control framework. Besides, we have security hardening on ACK [inaudible] and there are security management solution for data encryption at rest. In runtime layer, we have security center for Container Runtime Monitoring, and PSP support for powder security contexts automation control. This part is a feature illustration. Let me show some more details on our security features. The first feature is fine-grained access control, where you support both access control on Cloud Resource in management Layer, and Kubernetes Cluster Resource Access Control in that Layer. The administration could easily authorize one RAM sub-account on console with our [inaudible] RAM [inaudible] tablet. Also, we support customized [inaudible] and bending. Before the configuration finish, we will check the RAM authorization for Cloud results, and auto generate the RAM policy if management access control is not finished. For default configuration security, in the first step, we have hardened cluster control-plane security based on CIS Kubernetes benchmark. In the second step, we will ensure system pod, and the controllers are configurated using the best practice. Then the second step, we will also ensure there's no quit cause they were you vulnerabilities in system called images. All of the security hardening validation were integrated into our daily scanning job. For auditing, we support, different kinds of auditing like [inaudible] auditing, ingress traffic auditing and the Kubernetes resource event auditing. The agent from SRS service, will help us to collecting the log, show the main console and provides the powerful searching abilities. In auditor log, it can have the administrator to track of regions performed by different users, which is an essential part of security maintenance of resource. The ingress traffic auditing we can find the inbound and outbound traffic and the statistics of PV and UE. In event center, we can find the key event for cluster DevOps, like the events of image pull failed and the [inaudible] , and so on. We provide Cloud native supply and chain to deploy the only trusted container in Cloud. With Cloud Native supply chain, you can configure the validation policy to automatically block risky image to deploy. Besides, you can require image to be signed based on your own key during the deployment process. Then you can also enforce signature validation when deploying. For the DevSecOps scenario, your container registry service, you can freely combine tasks such as image building, image security scanning, image synchronization, and image distribution in a single delivery chain. The Cloud Native supply chain is a fully observable and a traceable, compare with the Docker containers. Sandbox containers enable your applications to run on a lightweight virtual machine, which provides an independent corner to enable enhanced security isolation. Sandbox containers are suitable for scenarios such as load isolation, among multi-tenant and isolation of untrusted applications. In addition to in-house security, Sandbox containers have little impact on performance and it can offer the same user experience as Docker containers, such as, future alpha logging, and monitoring, and elasticity. In container runtime, it's runtime monitoring and defense is an important security feature. In Alibaba Cloud Security Center, it support container risk detection and alerting, including the feature of malicious image, staff detection. In charging into containers, the container escape high-risk operation alerting and so on. In the picture which shows alerting and isolation for Graboid, which is first-ever minor crypto jacking warm found in image on Docker Hub. Security management is essential to enterprise container application on Cloud. For the security management solution, we have ACK-KMS plugin, which based on the Kubernetes encryption provide a framework. User could encode security data at rest with customized key in KMS service. Besides, we provide ACK security manager which help you to import using an synchronizer secret that measured by an external security management service. User can directly install it in our APP Catalog. Both of these two Solution is open source. You can find the code in GitHub. At the end, let me show some demo. Okay, let's begin the demo. I have logged into our Container Service console with my primary account. The first demo is about R-back authorizations. In authorization's page, you can see the support both RAM user and then RAM roles. In RAM roles tab, you can input the real name here, and R-back and will automatically validate the input to those names. Back to the RAM user tab, you can choose all of the users or just one. I will choose a user and then click modify permissions. This is the R-back access control page. You can see there's already exceeding permission boundary here, and then we suppose four candles preside permissions. For the administrator permissions, it means the authorized user will have all permissions for all kinds of Kubernetes results, then we also support customized permissions. You can create your own class or role in [inaudible] , and it will show in this pop menu. You can select the touch hydrate class role to bound your sub-account. I will add a new bounding. First I'll select add a cluster, then select namespace. Then select developer as a permission. The notice here means the selected the user has not finished with the RAM authorization on the target cluster. We have to finish these three steps on page. First I will copy this text and go to the RAM console. In the policy page, click the create policy and then include the name. Here we choose lag the script mode and the cases are task here. I have created a new policy. Go to the User Page and search the dehutest sub-account. Add permissions, and customer policies. Search the policy I have created. We have finished the RAM configurations. Then go back to the communal service page and click submit. Now you can see we have finished authorization. Then you [inaudible] authorization. I have slide to a new browser with a authorized sub-account where I refine the page, you can see the new authorized class are shown here. The other test are the permissions we have not configured [inaudible] permission. They should not have the permissions to list the namespace. In the Deployment page it can only say that, also write default namespace. Let's come into the second demo. Suppose a binary authorization solution for slave issue to create signing keys in the KMS console. From sleeve issued a truce the rights region and creates the key, here choose the RSA for the keys pack and the true SIGN/VERIFY for the purpose and input the alias name. Here we have created some keys for this demo. Then we go to the Container signature page in the Security Center Council. Firstly, we should create a witness, impose a name and this lag of keys we just created. In the security policy tab, we should create a policy. Select the Tajik cluster and the namespace image. The image would verified by these witness. Then input our description. The policy is created successfully and that we should enable it. Then we go to the container registry page. Firstly, we need to create a enterprise instance. Please note the specific here should choose advanced. Here I already create an instance today and we will reuse it in the instance page. I have created a repository namespace, you can find the image signature here. Create a signature rule, choose RSA-PSS-SHA and select the witness, then select the scope. All you make images in this namespace would be automatically signing by this rule. In the repository page, if the picture here is green color, it means the signature is enabled. Let's back into our container so it's console. Select the Tajik cluster and we try to log in to it. Mostly we can find the kritis validation webhook has installed successfully and then we try to deploy it at a deployment without sign image. As you can see, that deployment is denied because the image is not a task testing. Now we create a new deployment with the signing image, and you can see that the comment is created successfully and we can find the poll is running. The last demo is about container run-time detection and alert. In this video, for survey, create a stress web service, and then we draw a malicious command, with remote code excuse or abilities. Here is the remote commander and we back in to the Cloud Security Center Console, we can find the alerting on the host side and the network side. We can find attacker IP and URL and that post data. You can find the command-line here and then we switch to the handled page. We can find the malicious remote request is intercepted by our securities center. That's all demo today. Thank you for watching.
