Harden EKS/GKE Clusters

[upodroid]

Our build clusters run untrusted code and we should try to harden the cluster configuration and the pod configuration.

Kubernetes Best Practices:

• Prow pods which run untrusted should only be ran in the test-pods namespace
• hostNetwork should not be set to true for pods in the test-pods namespace
• Pods should be run with privileged set to false unless required, such as DinD jobs.
• Use the relevant cross-cloud workload identity tooling to access resources in a different cloud provider. We have workloads on AWS and GCP that access resources on a different cloud provider securely.

GKE Best Practices:

• GKE Nodes should be running with a custom Google service account with minimal privileges
• Workload Identity must be enabled and should be used to assume Google Service accounts
• Apply all the GKE hardening suggestions. https://cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster

EKS Best Practices:

• EKS nodes should be running with IAM principals with minimal privileges
• IRSA should be used to assume AWS IAM roles
• Apply all the EKS hardening suggestions. https://aws.github.io/aws-eks-best-practices/security/docs/iam/#recommendations

[upodroid]

/area infra
/area infra/aws
/area infra/gcp
/priority important-soon

[xmudrii]

EKS-related IAM improvements are tracked as part of #5160

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[xmudrii]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[xmudrii]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[xmudrii]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[xmudrii]

/remove-lifecycle stale