Your organization is transitioning to Google Cloud. You want to ensure that only trusted container images are deployed on Google Kubernetes Engine (GKE) clusters in a project. The containers must be deployed from a centrally managed Container Registry and signed by a trusted authority.
What should you do? (Choose two.)
To ensure that only trusted container images are deployed on Google Kubernetes Engine (GKE) clusters and that these images come from a centrally managed Container Registry and are signed by a trusted authority, you should: 1) Configure the trusted image organization policy constraint for the project to restrict deployment to images from a specified, trusted Container Registry. 2) Configure the Binary Authorization policy with respective attestations to ensure that only images signed by trusted authorities are allowed for deployment on GKE. These two steps will comprehensively cover both the central management of images and the trusted signing requirement.
To ensure that only trusted container images are deployed on Google Kubernetes Engine (GKE) clusters in a project and that the containers are deployed from a centrally managed Container Registry and signed by a trusted authority, you should consider the following options: Configure the trusted image organization policy constraint for the project (Option B): This will allow you to create an organization policy constraint that enforces the use of only trusted images from a specific Container Registry. You can specify the registry that must be used, ensuring that images are sourced only from that trusted location. Configure the Binary Authorization policy with respective attestations for the project (Option E): Binary Authorization for GKE allows you to create policies that enforce the use of only trusted container images. You can specify which images are trusted and require attestation from trusted authorities before deployment. This ensures that only signed and trusted images can be deployed on the GKE clusters in the project.
Options A, C, and D are not directly related to ensuring the use of trusted container images from a centrally managed Container Registry and signed by a trusted authority: A. Enabling Container Threat Detection in Security Command Center (SCC) helps with threat detection but does not directly enforce the use of trusted container images. C. Creating a custom organization policy constraint for Binary Authorization is redundant and unnecessary when Binary Authorization can be configured directly (Option E). D. Enabling PodSecurity standards to a "Restricted" level enforces certain security policies on pods but does not directly address the issue of ensuring trusted container images.
BC is correct answer
B is for Compute Engine images. I think it is CE C - custom constraints for Binary Auth on GKE -OK E - We provide in Binary Auth rule Container Registry from where, we can deploy images
it's an org policy constraint it applies to all kings of images
CE is correct
C and E
B. This policy ensures that only trusted images from specific Container Registry repositories can be deployed. This meets one of the requirements E. Binary Authorization ensures that only container images that are signed by trusted authorities can be deployed on GKE. Attestations are a component of this, as they provide a verifiable signature by trusted parties that an image meets certain criteria.
BE are correct!
Correct Answer: BE B: Configure the trusted image organization policy constraint for the project. E: Configure the Binary Authorization policy with respective attestations for the project.
B and E. This will create a policy that enforces Binary Authorization and specifies that only images from the centrally managed Container Registry can be deployed. C and E. This will create a policy that enforces Binary Authorization and specifies that only images that are signed by a trusted authority can be deployed. However, it does not specify the source of the images.
To ensure that only trusted container images are deployed on Google Kubernetes Engine (GKE) clusters in a project and that these containers are deployed from a centrally managed Container Registry and signed by a trusted authority, you should consider the following two actions: B. Configure the trusted image organization policy constraint for the project. Trusted image sources can be specified at the project level using organization policy constraints. This ensures that only images from trusted Container Registries can be deployed. E. Configure the Binary Authorization policy with respective attestations for the project. Binary Authorization allows you to specify a policy that will require images to be signed by trusted authorities before they can be deployed. You can configure this with attestations to indicate that certain steps, like vulnerability scanning and code reviews, have been completed.
BE are correct
What is the 'trusted image organization policy constraint'? Where is it defined and found? Can someone provide it?
https://cloud.google.com/compute/docs/images/restricting-image-access "Enact an image access policy by setting a compute.trustedImageProjects constraint on your project, your folder, or your organization."
It's C and E. A -> cannot be because it does not make sense for centrally managing images and validating signed images. B -> Cannot be, because that org policy only applies to Compute Disk images, not containers (https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints) C -> Correct,m because we can create custom org policy for GKE to enforce Binary Authorization for image atestation (https://cloud.google.com/kubernetes-engine/docs/how-to/custom-org-policies#enforce) D -> PodSecurity policies are not applicable for this use case E -> We need to configure Binary Authorization in order to setup attestations to only allow specific images to be deployed in the cluster (https://cloud.google.com/binary-authorization/docs/setting-up). So, it's C and E.