1. Overview
   1. Container Registry is a private container image registry that runs on Google Cloud.
   2. Container Registry supports Docker Image Manifest and OCI image formats
   3. Many use Dockerhub as a central registry for storing public Docker images
   4. To control access to images, use a private registry such as Container Registry
   5. Container Registry can be assessed through secure HTTPS endpoints, which allows users to push, pull, and manage images from any system, VM instance, or hardware
   6. Docker credential helper command-line tool can be used to configure Docker to authenticate directly with Container Registry
   7. Registries in Container Registry are named by the host and project ID
   8. Locations correspond to the multi-regions for Cloud Storage storage buckets
   9. When an image is pushed to a registry with a new hostname, Container Registry creates a storage bucket in the specified multi-region
   10. Cloud Storage bucket is the underlying storage for the registry
   11. Within a project, all registries with the same hostname share one storage bucket
   12. A registry can contain many images, and these images may have different versions
   13. To identify a specific version of the image within a registry, specify the image's tag or digest
   14. Tags are unique to one image within a registry
   15. Container Registry stores its tags and layer files for container images in a Cloud Storage bucket in the same project as the registry
   16. Access to the bucket is configured using Cloud Storage identity and access management
   17. By default, project Owners and Editors have push and pull permissions for that project's Container Registry bucket
   18. Project Viewers have pull permission only
   19. Before pushing or pulling images, authentication need to be configured
   20. Docker can be configured to use the gcloud command-line tool to authenticate requests to Container Registry
   21. Container Registry supports advanced authentication methods using access tokens or JSON key files
   22. Docker needs access to Container Registry to push and pull images
   23. Use the Docker credential helper command-line tool to configure Container Registry credentials for use with Docker
   24. Docker command-line tool, docker, can be used to interact directly with Container Registry
   25. When Container Registry API is enabled, Container Registry adds a service account to the project
   26. Google owns the Container Registry service account account, but it is specific to a project
   27. If the Container Registry service account is deleted or its permissions changed, certain Container Registry features will not work correctly
   28. Container Registry service account roles should not be modified or the account deleted
   29. Pub/Sub can be used to get notifications about changes to container images
   30. Compute Engine instances and Google Kubernetes Engine clusters can push and pull Container Registry images based on Cloud Storage scopes on the instances
   31. Images stored in Container Registry can be deployed to the App Engine flexible environment
   32. Container Registry works with several popular continuous delivery systems
   33. Container Registry can be integrated with external services
2. Images
   1. Managed base images are base container images that are automatically patched by Google for security vulnerabilities
   2. When a container is deployed, two separate operating systems and images are chosen
   3. Node or host image is the operating system on which the container runs
   4. Container image is the operating system used by the container itself
   5. The container image is built by taking an operating system base image, and adding the packages, libraries, and binaries needed for the application
   6. Google maintains base images for building its own applications, including Google Cloud services like Google App Engine
   7. Managed base images have security properties which can make them desirable for some uses
   8. They are regularly scanned for known vulnerabilities, from the CVE database
   9. Base image security scan uses the same functionality as Container Registry Vulnerability Scanning
   10. When a patch is available for a found vulnerability, Google applies that patch
   11. Base images are built reproducibly, so there is a verifiable path from the source code to the binary
   12. Base images can be verified by comparing it to the GitHub source, ensuring that the build has not introduced any flaws
   13. They are stored on Google Cloud, so can be pulled directly from the environment without having to traverse networks
   14. Base images can be pulled using Private Google Access
   15. Base images can be used outside of Google Cloud
   16. Managed base images are available in GCP Marketplace
   17. Support for managed base images is subject to the lifecycles of the corresponding OS distributions
   18. Unless otherwise noted, Google publishes updated images at least monthly
   19. Published updates include security updates and other updates installed for operating system versions that are in the mainstream support stage of their lifecycles
   20. When an operating system version enters its extended lifecycle stage, Google no longer provides updated images
   21. Google generally does not backport new features to these versions in the extended lifecycle stage or past the extended lifecycle
   22. Distroless images are minimal, language-focused images
   23. Container Registry's Docker Hub Mirror offers frequently requested Docker Hub images, including base images
3. Analysis
   1. Container Analysis provides vulnerability scanning and metadata storage for software artifacts
   2. The service stores metadata and makes it available for consumption through an API
   3. The metadata comes from vulnerability scanning, other Cloud services, and third-party providers
   4. Container Analysis monitors vulnerability information to keep it up to date
   5. With incremental scanning, Container Analysis scans new images as they are uploaded
   6. The scan gathers metadata based on the container manifest and updates metadata every time the image is re-uploaded (re-pushed)
   7. With continuous analysis, Container Analysis continuously monitors the metadata of scanned images in Container Registry for new vulnerabilities
   8. This type of analysis pertains only to package vulnerabilities and does not include other kinds of metadata.
   9. Container Analysis performs continuous analysis only for images that have been pulled in the last 30 days
   10. When the scan of an image is completed, the produced vulnerability result is the collection of vulnerability occurrences for that image
   11. The severity levels are qualitative labels that reflect factors such as exploitability, scope, impact, and maturity of the vulnerability
   12. If a vulnerability enables a remote user to easily access a system and run arbitrary code without authentication or user interaction, that vulnerability would be classified as Critical
   13. Effective severity is the severity level assigned by the Linux distribution
   14. If distribution-specific severity levels are unavailable, Container Analysis uses the severity level assigned by the note provider
   15. CVSS score is the Common Vulnerability Scoring System score and associated severity level
   16. For a given vulnerability, the severity derived from a calculated CVSS score might not match the effective severity
   17. Linux distributions that assign severity levels use their own criteria to assess the specific impacts of a vulnerability on their distributions
   18. A high-level piece of metadata, such as a vulnerability or build information, is called a note
   19. When Container Analysis analyzes an image, each instance of a note that it finds is identified as an occurrence
4. Logging
   1. Google Cloud services write audit logs to help answer the questions, "Who did what, where, and when?"
   2. Cloud projects contain only the audit logs for resources that are directly within the project
   3. Other entities, such as folders, organisations, and billing accounts, each contain the audit logs for the entity itself
   4. Cloud Audit Logs maintains Admin Activity audit logs, Data Access audit logs and System Event audit logs
   5. Container Analysis writes Admin Activity audit logs, which record operations that modify the configuration or metadata of a resource
   6. Only if explicitly enabled, Container Analysis writes Data Access audit logs
   7. Data Access audit logs contain API calls that read the configuration or metadata of resources, as well as user-driven API calls that create, modify, or read user-provided resource data
   8. Data Access audit logs do not record the data-access operations on resources that are publicly shared or that can be accessed without logging into Google Cloud
   9. Container Analysis does not write System Event audit logs
   10. Admin Activity audit logs are always enabled and can't be disabled
   11. Data Access audit logs are disabled by default and are not written unless explicitly enabled, with the exception of Data Access audit logs for BigQuery, which cannot be disabled
   12. The Data Access audit logs configured can affect logs pricing in Cloud Logging
   13. Cloud Identity and Access Management permissions and roles determine which audit logs can be viewed or exported
   14. Logs reside in projects and in some other entities including organizations, folders, and billing accounts
   15. If you are using audit logs from a non-project entity, such as an organisation, then change the Project roles to suitable organisation roles
   16. Audit logs can be exported in the same way as any other kinds of logs
   17. To keep audit logs for a longer period of time or to use powerful search capabilities, export audit logs to Cloud Storage, BigQuery, or Pub/Sub
   18. Pub/Sub can be used to export logs to other applications and repositories
   19. To manage audit logs across an entire organization, create aggregated export sinks that can export logs from any or all projects in the organization
   20. If Data Access audit logs are over their logs allotments, export and exclude the Data Access audit logs from Logging
   21. Cloud Logging does not charge for audit logs that cannot be disabled, including all Admin Activity audit logs
   22. Cloud Logging charges for Data Access audit logs explicitly requested