Consider both internal processes for creating your artifacts and the usage by consumers of your artifacts when you create your repositories.
Repository formats
Each repository is associated with a specific artifact format. For example, a Docker repository stores Docker images. You can create multiple repositories for each format in the same Trusted Cloud project.
Repository modes
Standard repository
Standard repositories are regular Artifact Registry repositories for your private artifacts. You upload and download artifacts directly with these repositories and use Artifact Analysis to scan for vulnerabilities and other metadata.
To create standard repositories, follow the steps in Create standard repositories.
Repository location
You can create one or more repositories in a supported region. A good repository location balances latency, availability, and bandwidth costs for data consumers. Your organization might also have specific compliance requirements.Project structure
Your resource hierarchy is the way that you organize your resources across Trusted Cloud projects. The structure that you choose depends on factors such as data governance requirements, trust boundaries, and team structure.
There are two general approaches for setting up your repositories in multi-project organizations.
- Centralize repositories
- Create all repositories in a single project and then grant access to principals from other projects at the repository level. This approach can be more effective when a single person or team handles repository administration and repository access across your organization.
-
- Project-specific repositories
- Create repositories in projects that store and download artifacts. This approach might be required when you have data governance policies or trust boundaries that require more project-level separation and control of resources.
Access control
Repositories are only accessible with appropriate permissions unless you configure the repository for public access. You can grant permissions at the project or repository level.
Some Trusted Cloud services use default service accounts with default permissions to repositories in the same Trusted Cloud project. However, these default might not be suitable for your software development process or might not comply with security or policy requirements in your organization. Your repository administrator must explicitly grant these services access to repositories if:
- Artifact Registry is in a different project than the service that is interacting with it.
- You are using custom IAM roles with the default service accounts instead of the predefined role.
- You are not using the default service account for the Trusted Cloud service.
For other principals that require access to repositories, your repository administrator must grant access. Following the security principle of least privilege, grant the minimum required permissions. For example:
- You deploy container images in Artifact Registry to GKE clusters in several different projects. The service account for nodes in these clusters only require read access to repositories.
- You have a development repository for applications that are in development and production repository for applications that are released. Developers require read and write access to the development repository and read-only access to the production repository.
- You have a demo repository with sample applications. Your sales team only requires read-only access to download the demos.
Data encryption
By default, Trusted Cloud by S3NS automatically encrypts data when it is at rest using Google Cloud-powered encryption keys. 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).
Artifact Registry also supports organization policy constraints that can require CMEK to protect resources.
Labels
Labels provide a way to organize resources specific to a Trusted Cloud service. In Artifact Registry, you can add labels to repositories so that you can group them together or filter repository lists by label. For example, you can use labels to group repositories by development stage or by team for automation or billing purposes. For more information about creating and using repository labels, see Labelling repositories.