Design permissioning setup

This document outlines best practices for permissioning design in a Google Distributed Cloud (GDC) air-gapped universe. The following topics are covered:

Although the following designs are recommended, it's not required to follow them exactly as prescribed. Each GDC universe has unique requirements and considerations that must be satisfied on a case-by-case basis.

Configure an identity provider per organization

An operator must configure one or more identity providers per organization. An administrator then connects to an identity provider to manage authentication services for applications in the GDC universe.

You might have a scenario where your company has multiple departments with separate organizations, and each organization connects to the same identity provider for authentication. In that case, it is your responsibility to understand and audit the combination of privileges a user has across organizations. Ensure that a user with privileges in multiple organizations does not violate the requirements for separating workloads into distinct organizations.

Alternatively, you might have a scenario where different sets of users use different identity providers to authenticate within a single organization, such as when multiple vendor teams work together in a single organization. Consider whether consolidating user identities into a single identity provider or maintaining separate identity providers works best with your company's approach to identity management.

Configure multi-factor authentication for your identity provider

GDC relies on your IAM platform for authentication, including additional security settings such as multi-factor authentication. It is good practice to configure multi-factor authentication with a physical key for any user that might potentially access sensitive resources.

Restrict managed services and marketplace services

You might prefer to block some projects from certain services, to either limit the potential attack surface in a project or avoid use of unapproved services. By default, managed services like Artificial Intelligence and Machine Learning are available to use in any project. In comparison to managed services, marketplace services must first be enabled for the organization.

To deny service access from projects, apply Gatekeeper constraints against the custom resource definition of a service and a list of namespaces. The approach to deny access with Gatekeeper applies to managed and marketplace services.

Manage kubeconfig files for multiple clusters

Different operational tasks require a connection to different clusters. For example, you perform tasks like binding an IAM role to a project, and tasks like deploying a Kubernetes Pod resource on a Kubernetes cluster.

When using the GDC console, you don't need to be aware of which underlying cluster performs a task, as the GDC console abstracts away the low-level operations like connecting to a cluster.

However, when working with the gdcloud CLI or kubectl CLI, you might have multiple kubeconfig files for accomplishing your tasks. Ensure that you sign in using kubeconfig credentials for the appropriate cluster for your task.

Best practices for Kubernetes service accounts

For Kubernetes service accounts, authorization is based on a secret token. To mitigate the risk of service account tokens, consider the following best practices:

  • Avoid downloading persistent service account credentials for use outside of GDC.
  • Be aware of Kubernetes escalation paths for users or service accounts who have the ability to create and edit pods.
  • Set the expirationSeconds field to a short time period for the service account token projection of your workloads.
  • Regularly rotate service account credentials.

Consider principle of least privilege

Consider the principle of least privilege (PoLP) when granting role bindings to users. In accordance with PoLP, consider assigning only privileges required to complete a task.

For example, you grant the Project IAM Admin role within a single project to a user, so that this user delegates authority to grant roles within that project. This user then grants granular roles to other developers in the project based on the specific services they use. The Project IAM Admin role must be restricted to a trusted lead because this role could be used to escalate privilege, granting oneself or others additional roles in the project.

Audit regularly for excessive privileges

Be sure to review roles granted within your organization and audit against excessive privilege. You must ensure that the roles granted are necessary for an individual user to complete their job, and that combinations of roles across projects don't lead to an escalation or exfiltration risk.

If your company uses multiple organizations, we don't recommend that an individual user has highly privileged roles across multiple organizations, as this might violate the reason for separating organizations in the first place.