Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Security best practices for kubernetes deployment

9,177 views

Published on

Security best practices for a Kubernetes Deployment - from development, through build, ship, networking and run time controls.
Was presented at New York Kubernetes meetup https://www.meetup.com/New-York-Kubernetes-Meetup/events/237790149/

Published in: Software
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Ho can we do password rotation in kubernetes all of my containers using DB hosted externally and they reset password very frequently how can we do password rotation in kubernetes
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Security best practices for kubernetes deployment

  1. 1. Copyright @ 2017 Aqua Security Software Ltd. All Rights Reserved. Security Best Practices for Kubernetes Deployment Michael Cherny Head of Research, Aqua Security
  2. 2. 2 WHO AM I  Head of Security Research at Aqua Security, a leader in container security  20 years of building security products, development and research  Held senior security research positions at Microsoft, Aorato and Imperva.  Presented at security conferences, among them, BlackHat Europe, RSA Europe and Virus Bulleting.
  3. 3. 3 BUILD SECURITY ALIGNED WITH DEVOPS Build Ship Cluster Environment Networking and Runtime Monitoring Productio n Dev. / Testing  
  4. 4. BUILD AND SHIP
  5. 5. 5 BUILD AND SHIP  Ensure That Only Authorized Images are Used in Your Environment  Ensure That Images Are Free of Vulnerabilities  Integrate Security into your CI/CD pipeline
  6. 6. 6 SECURITY INTEGRATED WITH CI/CD Build • Only vetted code (approved for production) is used for building the images ShipTest  
  7. 7. 7 SECURITY INTEGRATED WITH CI/CD Build • Implement Continuous Security Vulnerability Scanning • Regularly Apply Security Updates to Your Environment ShipTest  
  8. 8. 8 SECURITY INTEGRATED WITH CI/CD Build • Use private registries to store your approved images - make sure you only push approved images to these registries ShipTest  
  9. 9. CLUSTER ENVIRONMENT
  10. 10. 10 SSH LIMIT DIRECT ACCESS TO KUBERNETES NODES  Limit SSH access to Kubernetes nodes  Ask users to use “kubectl exec”
  11. 11. 11 CONSIDER KUBERNETES AUTHORIZATION PLUGINS  Enables define fine-grained-access control rules  Namespaces  Containers  Operations  ABAC mode  RBAC mode  Webhook mode  Custom mode
  12. 12. 12 CREATE ADMINISTRATIVE BOUNDARIES BETWEEN RESOURCES  Limits the damage of mistake or malicious intent  Partition resources into logical groups  Use Kubernetes namespaces to facilitate resource segregation  Kubernetes Authorization plugins to segregate user’s access to namespace resources
  13. 13. 13 CREATE ADMINISTRATIVE BOUNDARIES BETWEEN RESOURCES  Example: allow ‘alice’ to read pods from namespace ‘fronto’ { "apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": { "user": "alice", "namespace": "fronto", "resource": "pods", "readonly": true } }
  14. 14. 14 DEFINE RESOURCE QUOTA  Resource-unbound containers in shared cluster are bad practice  Create resource quota policies  Pods  CPUs  Memory  Etc.  Assigned to namespace
  15. 15. 15 DEFINE RESOURCE QUOTA EXAMPLE  computer-resource.yaml apiVersion: v1 kind: ResourceQuota metadata: name: compute-resources spec: hard: pods: "4“ requests.cpu: "1“ requests.memory: 1Gi limits.cpu: "2“ limits.memory: 2Gi  kubectl create -f ./compute-resources.yaml -- namespace=myspace
  16. 16. 16 SAFELY DISTRIBUTE YOUR SECRETS  Storing sensitive data in docker file, POD definition etc. is not safe  Centrally and securely stored secrets  Manage user access  Manage containers/pods access  Store securely  Facilitate secrets expiry and rotation  Etc.
  17. 17. 17 KUBERNETES SECRETS  Secret object  As file  As Environment variable  Risks  Secrets stored in plain text  Is at rest  No separation of duties: operator can see secret value  Secrets are available, even if there is no container using it
  18. 18. 18 KUBERNETES SECRETS - EXAMPLE  echo -n "admin" > ./username.txt echo -n "1f2d1e2e67df" > ./password.txt  kubectl create secret generic db-user-pass --from- file=./username.txt --from-file=./password.txt secret "db-user-pass" created  kubectl get secrets  Kubectl describe secrets/db-user-pass
  19. 19. 19 KUBERNETES SECRETS - EXAMPLE  It call also be done manually  echo -n "admin" | base64 YWRtaW4=  echo -n "1f2d1e2e67df" | base64 MWYyZDFlMmU2N2Rm apiVersion: v1 kind: Secret metadata: name: mysecret type: Opaque data: username: YWRtaW4= password: MWYyZDFlMmU2N2Rm  kubectl create -f ./secret.yaml
  20. 20. NETWORKING
  21. 21. 21 IMPLEMENT NETWORK SEGMENTATION  “Good neighbor” compromised application is a door open into cluster  Network segmentation  Ensures that container can communicate only with whom it must
  22. 22. 22 IMPLEMENT NETWORK SEGMENTATION  Cross-cluster segmentation can be achieved using firewall rules  “dynamic” nature of container network identities makes container network segmentation a true challenge  Kubernetes Network SIG works on pod-to-pod network policies  Currently only ingress policies can be defined
  23. 23. 23 IMPLEMENT NETWORK SEGMENTATION: EXAMPLE  Enable using an annotation on the Namespace kind: Namespace apiVersion: v1 metadata: annotations: net.beta.kubernetes.io/network-policy: | { "ingress": { "isolation": "DefaultDeny" } } kubectl annotate ns <namespace> "net.beta.kubernetes.io/network-policy={"ingress": {"isolation": "DefaultDeny"}}"
  24. 24. 24 IMPLEMENT NETWORK SEGMENTATION: EXAMPLE apiVersion: extensions/v1beta1 kind: NetworkPolicy metadata: name: test-network-policy namespace: default spec: podSelector: matchLabels: role: db ingress: - from: - namespaceSelector: matchLabels: project: myproject - podSelector: matchLabels: role: frontend ports: - protocol: tcp port: 6379 kubectl create -f policy.yaml
  25. 25. RUNTIME
  26. 26. 26 RUNTIME  Implement “least privileges” principal  Security Context control security parameters to be assigned  Pod  Containers  Pod Security Policy  Consider Kubernetes admission controllers:  “DenyEscalatingExec” – for containers/pods with elevated privileges  “ImagePolicyWebhook” – Kubernetes support to plug external image reviewer  “AlwaysPullImages” – in multitenant cluster
  27. 27. 27 SECURITY CONTEXT Security Context Setting Description SecurityContext->runAsNonRoot Indicates that containers should run as non-root user SecurityContext->Capabilities Controls the Linux capabilities assigned to the container. SecurityContext->readOnlyRootFilesystem Controls whether a container will be able to write into the root filesystem. PodSecurityContext->runAsNonRoot Prevents running a container with ‘root’ user as part of the pod
  28. 28. 28 SECURITY CONTEXT: EXAMPLE apiVersion: v1 kind: Pod metadata: name: hello-world spec: containers: # specification of the pod’s containers # ... securityContext: readOnlyRootFilesystem: true runAsNonRoot: true
  29. 29. 29 IMAGE POLICY WEBHOOK  api.imagepolicy.v1alpha1.ImageReview object describing the action  Fields describing the containers being admitted, as well as any pod annotations that match *.image- policy.k8s.io/*
  30. 30. 30 IMAGE POLICY WEBHOOK: EXAMPLE { "apiVersion":"imagepolicy.k8s.io/v1alpha1", "kind":"ImageReview", "spec":{ "containers":[ { "image":"myrepo/myimage:v1“ }, { "image":"myrepo/myimage@sha256:beb6bd6a68f114c1dc2ea4b28db81bdf91de202a9014972bec5e4d9171d 90ed“ } ], "annotations":[ "mycluster.image-policy.k8s.io/ticket-1234": "break-glass“ ], "namespace":"mynamespace“ } }
  31. 31. 31 MONITORING AND VISIBILITY  Log everything  Cluster-based logging  Log container activity into a central log hub.  Use Fluentd agent on each node  Ingested logs using  Google Stackdriver Logging  Elasticsearch  Viewed with Kibana.
  32. 32. SUMMARY
  33. 33. 33 SECURITY ALIGNED WITH DEVOPS Build Ship Cluster Environment Networking and Runtime Monitoring Productio n Dev. / Testing Only vetted code can be used for build Scan images against known vulnerabilities Use private registries Only approved images are pushed Only use kubectl Fine-grained-access control to resources Create administrative boundaries and assign resource quotas Manage your secrets Implement “least privileges” principal Isolate container networks in logical application groups Log everything Integrates with SIEM and monitoring systems  
  34. 34. THANK YOU Michael Cherny cherny@aquasec.com @chernymi https://www.aquasec.com

×