Search the Community

Google Cloud strives to make good security outcomes easier for customers to achieve. As part of this continued effort, we are releasing an updated and stronger set of security defaults that are automatically implemented for new customers. Google Cloud customers with a verified domain receive an organization resource, which is used as the root of the resource hierarchy and to provide scalable controls to your cloud environment through the use of the Organization Policy Service. With the release of secure-by-default organization resources, potentially insecure postures and outcomes are addressed with a bundle of organization policies that are enforced as soon as a new organization resource is created. Existing organization resources are not impacted by this change. These changes are part of the ongoing efforts to make it easier for customers to start with security best practices from the beginning of their cloud adoption. How stronger defaults can help keep environments more secureThe organization policies we enforce broadly span Identity and Access Management, Storage, and Essential Contacts. Identity and Access Management constraints Changes to default organization policy constraints for IAM enforce additional security policies for service accounts and restricting domain sharing. These constraints include: Disable service account key creation (iam.disableServiceAccountKeyCreation) - Prevent users from creating persistent keys for service accounts to decrease the risk of exposed service account credentials. Most scenarios can authenticate with a more secure alternative to service account keys. Instead of allowing unqualified use of service account keys, choose the right authentication method for your use case, and allow an exception to use service account keys only for scenarios that cannot use any of the more secure alternatives.Disable Automatic IAM Grants for Default Service Accounts (iam.automaticIamGrantsForDefaultServiceAccounts) - Prevent default service accounts from receiving the overly-permissive IAM role “Editor” at creation. Services built on top of Google Compute Engine, including managed services like Dataproc, Dataflow, and Google Kubernetes Engine, also rely on the default compute service account. Instead of relying on the default service account and Editor role, we recommend that you specify dedicated service accounts for each application and grant it the minimum IAM roles required to do the necessary tasks. For more information, see best practices for using service accounts.Disable Service Account Key Upload (iam.disableServiceAccountKeyUpload) - Avoid the risk of leaked and reused key material with service account keys.Domain restricted sharing (iam.allowedPolicyMemberDomains) - Limit IAM policies to only allow managed user identities in customer selected domain(s) to access resources inside their organization.Storage constraint The new default organization policy constraint for storage enforces uniform bucket-level access (storage.uniformBucketLevelAccess). This constraint prevents Cloud Storage buckets from using per-object ACLs (a separate system from IAM policies) to provide access, enforcing consistency for access management and auditing. Essential Contacts constraint The new default policy constraint for Essential Contacts limits contacts to only allow managed user identities in customer selected domain(s) to receive platform notifications (essentialcontacts.allowedContactDomains). This constraint helps ensure that important notifications from the platform can only be sent to users in selected domain(s). Modify default organization policiesYou might choose to modify or disable these security settings enforced by default organization policies. For example, you might have a workload that can only authenticate with service account keys and cannot use any of the more secure authentication methods. In this case, we recommend that you modify the policy as narrowly as possible to grant an exception to the relevant projects. For guidance to modify the default organization policies, see manage enforcement of organization policies. Getting started with Organization Policy ServiceThese default Organization Policy Service constraints can be a powerful and easy-to-use way for platform administrators to provide more secure access to cloud resources in a least privileged manner. Moving forward we’ll continue to invest in strengthening default configurations, shifting from requiring customers to harden solutions, to providing documentation on how to adapt security as needed — there’s more to come in 2024. In the meantime, you can learn more about Organization Policy Service by reviewing these resources: Introduction to the Organization Policy ServiceUnderstanding constraintsUnderstanding hierarchy evaluationCreating and managing organization policiesSetting an organization policy with tagsView the full article

Improve Kubernetes cost and reliability with the new Policy Controller policy bundleView the full article

Policies are rules that HashiCorp Terraform Cloud enforces at the Terraform run phase that can help with security, compliance, and cost management. Policies can be defined in Terraform Cloud using Sentinel and the Open Policy Agent (OPA) policy as code frameworks. Today, we are excited to announce a new feature that addresses a critical challenge faced by customers in policy as code integration with Terraform Cloud: policy runtime version management; a new feature that enables users to select a specific Sentinel or OPA runtime version for their policy sets. This update introduces a policy runtime version pinning feature that provides Terraform Cloud users with more control, flexibility, and stability in their policy deployments. Policy runtime version management enables users to select specific policy as code runtime versions in Terraform Cloud to reduce the impact of version conflicts, unexpected upgrades, and bugs, making policy enforcement more stable and efficient... View the full article

Today, we’re excited to announce the native support for enforcing Kubernetes network policies with Amazon VPC Container Networking Interface (CNI) Plugin. You can now use Amazon VPC CNI to implement both pod networking and network policies to secure the traffic in your Kubernetes clusters. Native support for network policies has been one of the most requested features on our containers roadmap... View the full article

SREs and security practitioners spend a lot of time creating secure and reliable infrastructure for web applications. In parallel, engineering teams also spend significant time on release engineering and the release pipeline, ensuring it’s secure and fast. Release pipelines are made up of version control systems (VCS) (e.g., GitHub, Gitlab, Bitbucket), continuous integration/continuous deployment (CI/CD) pipeline configuration (e.g., Jenkins, GitHub Actions, Terraform Cloud), OSS packages, and tagging. When building release pipelines, the goal is to create consistent, auditable, and agile build and deployment processes ... Read More: https://bridgecrew.io/blog/software-supply-chain-security-vcs-policies/