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.

Shift Left: Security in a Containerized World


Published on

There has been a movement recently about finding security-related issues earlier in the development and deployment pipeline. It's about catching security issues before things the fan. In this presentation, we will talk about what it means to shift left from the container security point of view.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Shift Left: Security in a Containerized World

  1. 1. Gunjan Patel Shift Left ⬅️ Security In a Containerized World
  2. 2. Cloud puns Q: Why did the cloud do drugs? A: Atmospheric pressure Son: Dad, what are clouds made up of? Dad: A bunch of Linux servers, son. Sorry…
  3. 3. The Technology Adoption Curve Serverless Containers VMs Appliances
  4. 4. The Evolution
  5. 5. What is Shift Left? • Security is not an On/Off thing, it’s a spectrum • Security as part of SDLC
  6. 6. Why do Devs and Ops people like k8s? CODE CODE CODE Make Better Use of Human Time
  7. 7. Process then vs process now Code Packaging Infrastructure Design Provision Hosts/ Config Deploy Code Container Image & App Config Deploy
  8. 8. Security should not be an afterthought
  9. 9. Security VS Developers/DevOps • Low Risk • Process • Formal • Slow and Thoughtful v/s • Try new things • Automate • Informal • Quick, fail fast
  10. 10. Where do you place the controls? Container Orchestration Network Host OS Libraries Code Container Orchestration Network Host OS Libraries Code Container Orchestration Network Host OS Libraries Code Container Orchestration Network Host OS Libraries Code Data Center VM in Cloud K8s in Cloud Serverless Securitycontrol
  11. 11. Kubernetes Security Concepts Container Escapes Kernel Exploits Seccomp SELinux Pod Security Policies App Policy (istio) Image Scanning Network Policies RBAC Least Privilege OS Hardening Logging
  12. 12. Left AND Right
  13. 13. Container Security Best Practices Securing the build pipeline: • Verifying the image source (registry) • Using official base images • Locking down access to the image registry (who can push/pull) • Scanning container image layers for CVEs • Tagging and automatically preventing vuln images from running in certain clusters or preventing them from talking to other containers in the cluster Network security: • Securing services that are exposed to the internet using a Firewall • Locking down L3/4 network using NetworkPolicy • Create granular L7 policies using service mesh (such as istio) • Using mTLS to mutually authenticate containerized workloads (e.g. using istio) Securing the host: • OS lock down (like COS) • seccomp to restrict host syscall access from containers • SELinux to further isolate containers
  14. 14. Container Security Best Practices Securing container runtimes: • There are multiple container runtimes now: Docker, CRI (CRI-O, CRI-ContainerD), rkt • They all have different operational and security models. It’s important to make sure security configuration spans across container runtimes especially if the environment has multiple container runtimes in the cluster (e.g. different runtimes for orchestrator control plane and workloads) Admission control: • Using policies (example: pod security policy in k8s) to restrict which containers can run in the system for example: • non-privilaged containers • containers that don’t need write access to the file system • containers that don’t need certain syscalls Orchestrator configuration: • Managing orchestrator configuration and workload, service definitions/configurations version controlled (using git) • Cluster level policies (security policies, network policies, etc.) should go through change request and review process
  15. 15. Container Security Best Practices Cloud provider: • If you’re running your containers in a cloud, default security configuration (for orchestrator, container runtime, OS) can be different for different cloud providers • It is important to understand the version of orchestrator and container runtime components your cloud provider is running by default • If those components are modified from their open source version Orchestrator: • Orchestrator API access security using RBAC and NetworkPolicies • Be aware of which 3rd party plugins (CNIs, SNIs, CRIs) are running (binary/DaemonSet/controller) and what access do they have. If they’re running as privileged containers • Controlling access to the orchestrator control plane APIs from 3rd party plugins using RBAC, ServiceAccount
  17. 17. Privileged access on the host? CloudWatch logging enabled? Managed registry being used? Secure webhooks in use? EXTENDING COMPLIANCE CHECKS TO CONTAINER INFRASTRUCTURE 17 | © 2018, Palo Alto Networks. Confidential and Proprietary. RedLock and Evident More coming soon…
  18. 18.  Inbound security protection for Kubernetes (K8s) services  Automated learning of K8s services meta-data  Dynamic NAT policy updates  Outbound security controls INITIAL AVAILABILITY ON GOOGLE KUBERNETES ENGINE (GKE) Kubernetes Service Containers Kubernetes Service Kubernetes Service Containers Kubernetes Service GKE/Kubernetes Internet Network Traffic Management Traffic NETWORK THREAT PROTECTIONS FOR CONTAINER WORKLOADS IN GKE 18 | © 2018, Palo Alto Networks. Confidential and Proprietary.
  19. 19. Extending Host OS Protections To Containers Host-OS Exploit Protections • Local Privilege escalation • ROP exploits • Shellcode • Brute force • Reverse Shell Events Dashboard • Container process/namespace awareness • Container objects in events 19 | © 2015, Palo Alto Networks. Confidential and Proprietary.
  20. 20. FOUR STEPS TO SECURING YOUR CONTAINER INFRASTRUCTURE 20 | © 2018, Palo Alto Networks. Confidential and Proprietary. Registry Scanning Orchestrator ProtectionsHost-OS SecurityNetwork Protections EV
  21. 21. Containers Security Survey Chance to win a Google Home Mini
  22. 22. istio
  23. 23. What is ? • Load Balancing S V C - A S V C - B V 1 . 0 S V C - B V 2 . 1 80% 20% • Security, encryption • Metrics • Ingress/Egress • Add-ons: • Prometheus • Grafana • Zipkin • Service Graph • Failure tolerance
  24. 24. Demo
  25. 25. Thank you!