Enhancing Security: Google Cloud's Organizational Policy Change

-

Enhancing Security: Google Cloud's Organizational Policy Change

Google announced an upcoming organizational policy change set to take effect on June 16, 2024 continueing to bolster their security of our services, and this change marks another step in that direction so great job Google! 

Recieved via email today, tldr below:

What's Changing?

Starting June 16, 2024, Google Cloud administrators will gain the ability to dictate how Google Cloud responds in the event of a private Service Account Key being publicly exposed. This change is integral in fortifying the security of your Google Cloud environment.

Our systems are intricately linked with various programs, including the GitHub scanning program, enabling us to swiftly identify any instances of private Service Account Keys being exposed to the public eye. In addition to Google's vulnerability scanning these are great options for securing your workloads. 


Why is This Important?

Service Account Keys are crucial components of your Google Cloud environment, and their confidentiality must be maintained at all costs. Public exposure of these keys poses significant risks, potentially granting unauthorized individuals access to your data, allowing for unauthorized modifications, deletions, or even resource consumption, which could lead to severe disruptions. Users should strongly consider migrating to using Organizational controls.

Understanding the gravity of this situation, we're proactively taking measures to safeguard your environment and minimize potential threats.


What's Expected of You?

In preparation for this organizational policy change, we encourage you to take proactive steps. You have the autonomy to tailor the response according to your organization's needs:

  1. Opt-in Early: You can choose to opt-in early by setting the `IAM.serviceAccountKeyExposureResponse` constraint to `DISABLE_KEY`, activating immediate protection against any identified exposures.
  2. Opt-out Anytime: Conversely, if you prefer to retain control over the timing of the protection, you can opt-out at any time by setting the constraint to `WAIT_FOR_ABUSE`, allowing you to disable the protection temporarily.
  3. Do Nothing: If you opt not to take any action, rest assured that Google will activate the protection on your behalf come June 16, 2024, ensuring the security of your environment.

Conclusion

Security is a top priority for many of us in this space and this policy change reflects Google's unwavering commitment to fortifying your Google Cloud environment against potential threats. If you are a Google customer I urge you to consider the options available and take the necessary steps to align with these changes. 

For further details and guidance on implementing these changes, please refer to the Google documentation or reach out to your Google Cloud support team.

This blog post aims to succinctly communicate the upcoming organizational policy change regarding the handling of publicly exposed Service Account Keys on Google Cloud, outlining the significance of the change, and providing clear instructions for users on how to adapt to these modifications.

Popular

Federated user activity made easy

-
Image
 Federated user activity made easy. The other day I was auditing a sandboxed account in AWS and started investigating resources connected to a federated role for a group of students that are no longer enabled on the account. I noticed a few objects that should have been elsewhere or terminated after the fact, regardless, neither here nor there. After about 30 minutes of sifting through logs, creating custom queries, and trying to put them together, I lost interest because of the time and day-to-day priorities. I felt this was a good use case for me to test out some of the functionality of CloudGuard's investigation and correlation engine within the platform and try out this voice-over platform. Enjoy - Video below: if you feel inclined to research further, visit the product page
Read more

Google Cloud: Container Registry will be replaced by Artifact Registry

-
Spoiler Alert: (you've got some time) Container Registry will be replaced by Artifact Registry. Please upgrade your projects to Artifact Registry before March 18, 2025. On March 18, 2025 , Container Registry will be replaced by Artifact Registry . We understand this change may affect your production workloads, so we've put together resources to make this transition as smooth as possible for you. What do you need to know? To retain access to your container images, please take note of these critical dates and actions you need to take related to the Container Registry shutdown: March 18, 2025: You will no longer be able to push new images to Container Registry. April 22, 2025: You will lose access to existing images in Container Registry. To maintain access, you must copy them to the Artifact Registry before this date. May 22, 2025: All requests to the gcr.io domain will be handled exclusively by Artifact Registry. Ensure the Artifact Registry...
Read more

Meet Kaniko

-
Image
So, what is kaniko? Kaniko is a tool to build container images from a Dockerfile inside a container or Kubernetes cluster. Another great callout for me is that my CI provider, GitLab makes it super easy to implement in my pipelines. Kaniko doesn't depend on a Docker daemon and executes each command within a Dockerfile entirely in userspace. This enables building container images in environments that can't easily or securely run a Docker daemon, such as a standard Kubernetes cluster. How does Kaniko work? The kaniko executor image is responsible for building an image from a Dockerfile and pushing it to a registry. Within the executor image, we extract the filesystem of the base image (the FROM image in the Dockerfile). We then execute the commands in the Dockerfile, snapshotting the filesystem in userspace after each one. After each command, we append a layer of changed files to the base image (if there are any) and update image metadata. Highly recommend visiting their  repo  ...
Read more