Uploaded byAltoros
Shift Left: Security in a Containerized World
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.
Shift Left: Security in a Containerized World
- 1. twitter.com/Gunjan_Patel1 Gunjan Patel Shift Left⬅️ Security In a Containerized World github.com/gunjan5
- 2. Cloud puns Q: Whydid the cloud do drugs? A: Atmospheric pressure Son: Dad, what are clouds made up of? Dad: A bunch of Linux servers, son. Sorry…
- 3. The Technology AdoptionCurve Serverless Containers VMs Appliances
- 4.
- 5. What is ShiftLeft? • Security is not an On/Off thing, it’s a spectrum • Security as part of SDLC
- 6. Why do Devsand Ops people like k8s? CODE CODE CODE Make Better Use of Human Time
- 7. Process then vsprocess now Code Packaging Infrastructure Design Provision Hosts/ Config Deploy Code Container Image & App Config Deploy
- 8. Security should notbe an afterthought
- 9. Security VS Developers/DevOps •Low Risk • Process • Formal • Slow and Thoughtful v/s • Try new things • Automate • Informal • Quick, fail fast
- 10. Where do youplace 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. Kubernetes Security Concepts ContainerEscapes Kernel Exploits Seccomp SELinux Pod Security Policies App Policy (istio) Image Scanning Network Policies RBAC Least Privilege OS Hardening Logging
- 12.
- 13. Container Security BestPractices 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. Container Security BestPractices 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. Container Security BestPractices 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
- 16. 200+ SIGNATURES 30+ TOP CONTAINER APPS AND MORE… CONTAINERAPPS CONTAINER INFRA ONGOING RESEARCH CVEs TRACKED CONTAINER OS NETWORK THREAT PROTECTIONS FOR CONTAINER ENVIRONMENTS 16 | © 2018, Palo Alto Networks. Confidential and Proprietary.
- 17. Privileged access onthe 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. Inbound securityprotection 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. Extending Host OSProtections 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. FOUR STEPS TOSECURING YOUR CONTAINER INFRASTRUCTURE 20 | © 2018, Palo Alto Networks. Confidential and Proprietary. Registry Scanning Orchestrator ProtectionsHost-OS SecurityNetwork Protections EV
- 21. Containers Security Survey https://bit.ly/container-security-survey Chanceto win a Google Home Mini
- 22.
- 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.
- 25.