Containing our enthusiasm: All the Kubernetes security news from Google Cloud Next ‘19

At Google, we like to think of container security in three pillars: Secure to develop (infrastructure security protecting identities, secrets and networks); secure to build and deploy (vulnerability-free images, verification of what you deploy); and secure to run (isolating workloads, scaling, and identifying malicious containers in production). These pillars cover the entire lifecycle of a container, and help ensure end-to-end security.We’ve been hard at work to make it easier for you to ensure security as you develop, build, deploy, and run containers, with new products and features in Google Kubernetes Engine and across Google Cloud. Here’s what we recently announced at Next ‘19, and how you can use these for your container deployments—so there’s less cryptojacking, and more time for whale watching, as it were.Secure to develop, by making it easier to manage identities and secretsA frequent pain point in GKE is authentication from a container workload to another service on Google Cloud, such as Cloud SQL. Traditionally, there have been two main ways to do this. First, by over-provisioning permissions—for example, using the node’s built-in service account to authenticate, but this creates unnecessary security risks in the case that the pod is compromised. Second, by creating a new service account identity, and storing its key as a secret and injecting that secret into a pod—a cumbersome solution.With the upcoming workload identity feature, you can use Google IAM service accounts from Kubernetes pods without having to manage any secrets. Using workload identity, Kubernetes service accounts are associated with Google service accounts and, when a pod with that Kubernetes service account uses the application’s default credentials, a token exchange occurs and the pod is given a short-lived token for the specified service account. This helps you better scope which workloads can access which other services within your infrastructure.Another pain point has been granting and revoking users’ access through Kubernetes RBAC. Kubernetes RBAC is a core component of Kubernetes and important for fine-grained access control. However, you were previously only able to grant roles to GCP user accounts or Cloud IAM service accounts. Now, you can use Google Groups for GKE in beta. Any Google Group can now be used in an RBAC rule in GKE, provided a Cloud Identity administrator has enabled the group for use in access control rules. This allows you to use existing groups to provide access to large sets of users with a single rule, while ensuring that sensitive groups used exclusively for email distribution remain private. Google Groups for GKE greatly simplifies RBAC and account management.As for your secrets, we released another security measure to protect these a few months ago, with application-layer secrets encryption (beta), which lets you use a key in Cloud KMS to protect secrets at rest in GKE.Secure to build and deploy, with a well-protected software supply chainAnother area of focus at Next this year was to round out our secure software supply chain offerings, including the forthcoming general availability of Container Registry vulnerability scanning and Binary Authorization.Container Registry vulnerability scanning looks at the images in your private registry for known common vulnerabilities and exposures (CVEs) from multipleCVE databases. It displays the results in your registry, including whether a fix is available, so that you can take action. It performs this scan when a new image is added to the registry, as well as for existing images when a new vulnerability is added to the database. New in GA is support for more OSes; Container Registry vulnerability scanning is now available for Debian, Ubuntu, Red Hat Enterprise Linux, CentOS, and Alpine images.Binary Authorization is a deploy-time security control that ensures only trusted container images are deployed on Kubernetes Engine. Binary Authorization lets you define requirements for deployment—such as signed images and required scanning—so that only verified images are integrated into the build-and-release process. With the GA announcement, Binary Authorization introduces three new features:Global policy for GKE system containers. In order to use GKE, you need to run a number of GKE system containers in your environment. In the past, you had to manually ensure that only up-to-date and authentic system containers are deployed. With the GA of Binary Authorization, you can opt to only allow trusted system containers that are built and recognized by the GKE team to be deployed, gaining more control and visibility over your production environments.Dry-run, which allows customers to set a deploy policy in non-enforcement mode and use auditing to record and review any would-be blocked deployment. This gives you the flexibility to test out new policies without risking an interruption in your production release cycle.Support for KMS asymmetric keys (beta), allowing you to sign and verify container images using asymmetric keys generated by Cloud KMS, as well as support for generic PKCS signing keys in case you want to use your own PKI.Secure to run, thanks to isolation and early warningsYou can’t always control the contents of your workloads or be completely selective about what ends up in your environment. For example, you might be getting containers from your customers or third parties. When you run untrusted code, particularly in a multi-tenant environment, you want to be able to trust that the boundaries you have between your workloads is strong. The soon-to-be beta of GKE Sandbox brings Google’s gVisor sandboxing technology natively to GKE, using the Runtime Class. This provides you with a second layer of defense between containerized workloads, without changes to your applications, new architectural models, or added complexity. Container escape—when a compromised container gains access to the host and data in other containers—is a concern for anyone running sensitive workloads in containers. GKE Sandbox reduces the need for the container to interact directly with the host, shrinking the attack surface for host compromise, and restricting the movement of malicious actors.Whether you’re running your own (trusted) containers, or untrusted containers, however, you’ll want to lock down your Kubernetes configuration. We keep our hardening guide up to date,  leading you through the best practices to follow. At Next, we also introduced a simpler way with Security Health Analytics (alpha), which provides automated security checks for common misconfigurations in Google Cloud, including those discussed in the GKE hardening guide. The results of these checks are reported in the Cloud Security Command Center (Cloud SCC), so you have a single place to look at security reports for your clusters. (Don’t forget that we also have many partners who offer container runtime security, and who are directly integrated with the Cloud SCC!)Product announcements aside, Next ‘19 was also a great place to learn about container security. In case you missed them, catch the recordings of all the best container security content:Who protects what? Shared security in GKESecure Software Supply Chains on Google Kubernetes EngineSecuring Kubernetes SecretsGKE Networking DifferentiatorsKeyless entry: Securely access GCP services from KubernetesEnd-to-End Security and Compliance for your Kubernetes Software Supply ChainSecure Policy Management for Anthos (Cloud Services Platform)GKE Sandbox for Multi-tenancy and SecurityNext ‘19 was a milestone in our efforts to improve container security. See you again next year!
Quelle: Google Cloud Platform