🖊️
Notes
  • Notes
  • aws
    • CloudWatch
    • EKS
    • IAM
    • Key Management Service (KMS)
    • security
      • Attacks against AWS infrastructure
    • vpc
      • AWS Transit Gateway
  • azure
    • Azure AD
    • Azure CDN
    • DNS in Azure
    • Hub-spoke network topology
    • Identity and access management
    • Azure Landing zones
    • Storage
  • certifications
    • aws-sa-pro
    • Certified Kubernetes Administrator
  • containers
    • Examples
    • Linux Container Primitives
  • databases
    • Relational databases
  • gcp
    • IAM
  • git
    • Git
  • golang
    • Building Go projects
    • Concurrency
    • Project structure
  • infosec
    • SSH
    • SSL
  • Kubernetes
    • Admission Controllers
    • Autoscaling
    • Debugging
    • Multi-tenancy
    • Network Policies
    • Pod Priority
    • Pod Security Policies
    • Secrets
    • StatefulSet
    • additional-services
      • Debugging ArgoCD RBAC
      • open-policy-agent
  • misc
    • FFmpeg
    • PDFs
  • programming
    • Learning resources
    • concepts
      • Serialization
  • rabbitmq
    • Clustering and HA
    • Shovel plugin
  • shells
    • Bash
  • terraform
    • Moving resources between remote states
  • vim
    • Fzf (plugin)
    • Registers
    • Spell Check
  • linux
    • arch
      • Arch Linux installation
Powered by GitBook
On this page
  1. Kubernetes

Pod Security Policies

PreviousPod PriorityNextSecrets

Last updated 4 years ago

Mostly notes from watching TGI Kubernetes 078: Pod Security Policies

  • Pod Security Policies (PSP) are mechanism to prevent security aspects and capabilities of containers.

  • It is implemented by as an optional, but recommended, admission controller

  • Depending on the platform and Kubernetes distribution, PSP might need to enabled first

  • PSPs are cluster-wide resources

  • Kubernetes objects need to be granted privileges to use PSPs by RBAC

    • For example, create ClusterRole and then RoleBinding to bind it to specific namespaces

  • In my opinion, PSPs should be used in every production cluster

  • It is recommended to create multiple PSPs for different types of workloads. For example:

    • More privileged PSP for kube-system pods. Check TGIK 078 or Kube docs example for this.

    • Restricted for "normal" workloads

    • Something in between, if needed

  • You can use kubectl describe/get $OBJECT to check which PSP the pod is using from its annotations

  • In order to create a default and restrictive policy which always resolves, use ClusterRoleBinding and bind to rule to group system:authenticated

  • Security context configures security aspects for the pods

  • You can provide exceptions to PSPs on

    • workload level

      • binding the role to specific ServiceAccount

    • namespace level

  • Helper and auditing tool:

    • Advices the set of PSP against your workload

References

Kubernetes docs -

TGI Kubernetes 078: Pod Security Policies -

Configure a Security Context for a Pod or Container -

https://github.com/sysdiglabs/kube-psp-advisor
https://kubernetes.io/docs/concepts/policy/pod-security-policy/
https://youtube.com/watch?v=zErhwjPRKn8
https://kubernetes.io/docs/tasks/configure-pod-container/security-context/