This page describes Trusted Cloud services and features that help you to safeguard your artifacts.
Encryption at rest
By default, Trusted Cloud by S3NS automatically encrypts data when it is at rest using encryption keys managed by Google. If you have specific compliance or regulatory requirements related to the keys that protect your data, you can create repositories encrypted with customer-managed encryption keys (CMEK).
Access control
By default, all repositories are private. Follow the security principle of least privilege and only grant the minimum permissions that are required by users and service accounts.
Prevent data exfiltration
To prevent data exfiltration, you can use VPC Service Controls to place Artifact Registry and other Trusted Cloud by S3NS services in a network security perimeter.
Removing unused images
Remove unused container images to reduce storage costs and mitigate the risks of using older software. There are a number of tools available to help with this task, including gcr-cleaner. The gcr-cleaner tool is not an official Google product.
Shifting left on security
Integrating information security objectives into daily work can help increase software delivery performance and build more secure systems. This idea is also known as shifting left, because concerns, including security concerns, are addressed earlier in the software development lifecycle (that is, left in a left-to-right schedule diagram). Shifting left on security is one of the DevOps capabilities identified in the DORA State of DevOps research program.
To learn more:
- Read about the Shifting left on security capability.
Considerations for public repositories
Carefully consider the following cases:
- Usage of artifacts from public sources
- Making your own Artifact Registry repositories public
Using artifacts from public sources
The following public sources of artifacts provide tools you might use or dependencies for your builds and deployments:
However, your organization might have constraints that impact your use of public artifacts. For example:
- You want to control the content of your software supply chain.
- You don't want to depend on an external repository.
- You want to strictly control vulnerabilities in your production environment.
- You want the same base operating system in every image.
Consider the following approaches secure your software supply chain:
- Use standardized base images. Google provides some base images that you can use.
Public Artifact Registry repositories
You can make an Artifact Registry repository public by granting
the Artifact Registry Reader role to the allUsers identity.
If all your users have Trusted Cloud accounts, you can limit access
to authenticated users with the allAuthenticatedUsers identity instead.
Consider the following guidelines before making an Artifact Registry repository public:
- Verify that all artifacts you store in the repository are sharable publicly and do not expose credentials, personal data, or confidential data.
- By default, projects have unlimited per-user quotas. To prevent abuse, cap per-user quotas within your project.
Guidance for web applications
- The OWASP Top 10 lists the top web application security risks according to the Open Web Application Security Project (OSWAP).
Guidance for containers
The Center for Internet Security (CIS) has a Docker Benchmark for evaluating the security of a Docker container.
Docker provides an open source script called Docker Bench for Security. You can use the script to validate a running Docker container against the CIS Docker Benchmark.
Docker Bench For Security can help you verify many items in the CIS Docker Benchmark, but not all items are verifiable with the script. For example, the script cannot verify if the host for the container is hardened or if the container image includes personal data. Review all items in the benchmark and identify those that might need additional verification.