Securing the software supply chain
1. Securing the software supply chain
So you learned how to build and deploy software into hybrid and multi-cloud environments. But how do you ensure that the software supply chain is secure? In regards to software, the supply chain consists of the supply, build, and deployment. The supply that must be secured includes the source code, SAST, linting, dependency verification and acceptance, and proper source code management. Securing the build includes trust in both, the build tools and the output artifact, verify dependency provenance, build images, CVEs, container structure tests, base images, artifact repository, and image builds. Securing the deployment includes the repeatable processes used to deploy securely to any environment; artifact promotion across the several stages, such as development or production; approvals of those launches; and policy management for the software deployed in the environment. To secure the software supply chain, deploy trusted base images only. There are different ways to establish image trust. You can use base images, managed by Google, distribution images, or create your own. You can use the vulnerability scanning feature, in Artifact Registry, to guard against vulnerabilities based on CVE feeds. Artifact Registry offers more than container storage. It provides a range of security features. Regional repositories reduce network egress and keep the CI/CD pipeline in the same region, thus achieving data locality. Permissions granted at the repo level, create clear separation between accessing and publishing artifacts. Customer-managed encryption keys, encrypt your data with your own keys. A VPC Service perimeter adds an additional layer of security around your artifacts. And audit logging can be used to control who accesses artifacts. The Artifact Analysis API, allows you to store metadata associated with a resource. This metadata can later be retrieved to audit your software supply chain. When an image is stored in Artifact Registry, the registry automatically scans it for known Common Vulnerabilities and Exposures, or CVEs. Artifact Registry examines images and packages installed within them and works for many distributions including Debian, Ubuntu, and Alpine, Red Hat and CentOS images. Images are scanned when they are added to the registry, and the vulnerability database is updated. IAM permissions allow you to create a clear separation of duties for deployments. Promoters receive permissions to indicate that artifacts are deployment-ready, while approvers, acting as stakeholders, receive permissions to control the actual live deployment timing. Binary authorization ensures that the build goes through all stages of the pipeline and that only properly signed containers are deployed to production. Policy enforcement can be integrated directly into your clusters. Binary authorization supports signature verification and image allow lists and can be used to verify that images are built by a trusted CI/CD pipeline. Images pass security and quality tests, like vulnerability scans or QA tests. And only explicitly allowed third-party images are deployed. Binary authorization formalizes and codifies an organization's deployment requirements, by integrating with the desired CI/CD stages to produce signatures or attestations as an image passes through. Binary authorization acts as an admission controller by preventing images that do not meet these criteria from being deployed. In Kubernetes Engine, this is implemented with the pod creation API using the image policy admission controller. Binary authorization also integrates with Cloud audit logging to record failed pod creation attempts for later review. A common source of production vulnerability is unpatched third-party software. These images are not built in-house, so they don't have the necessary attestations from a trusted CI/CD process. This is why, in addition to signature based verification, binary authorization policy also supports using name patterns to allow list images. A user can specify a repository, path, or particular set of images that are allowed to deploy. You can have a centralized allow list of all the third-party images and easily identify, locate, and update when a third-party image becomes outdated or vulnerable. Finally, Config Sync enforces compliance policies. It uses an admission controller inside your cluster, which ultimately allows applications and configurations to be deployed in your cluster.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.