Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Security at Cloud Native Speed

Chris Short
November 19, 2019

Security at Cloud Native Speed

Cloud native technologies are increasingly used by organizations to provide a competitive advantage. Containers and Kubernetes jumpstart developer productivity but, they could increase security teams’ workloads. Threat vectors span cloud providers, control planes, developer tooling, and applications in environment hybrid environments. Use these technologies and cultures to improve security and reduce blast radius while improving velocity. This talk will analyze human tendencies and provide tips to improve security postures in cloud native environments.

Chris Short

November 19, 2019
Tweet

More Decks by Chris Short

Other Decks in Technology

Transcript

  1. Security at Cloud Native Speed Chris Short Principal Technical Marketing

    Manager Cloud Native Ambassador PodCTL Co-host
  2. ◦ @ChrisShort ◦ Red Hat OpenShift ◦ PodCTL > whoami

    ◦ CNCF Ambassador ◦ DevOps’ish ◦ KubeWeekly
  3. ◦ Struggles ◦ Velocity ◦ CD for Security > column

    README.md ◦ Platform Security ◦ Speed Makes Us Safer ◦ Continuous Learning
  4. Using cloud native tools Struggles ◦ Cloud Providers ◦ Kubernetes

    ◦ Operators ◦ Helm Charts ◦ Libraries ◦ Third Party APIs ◦ Internal APIs ◦ CNCF Landscape...
  5. Velocity Enter the Cloud Native Trail Map… ◦ Containerization ◦

    CI/CD ◦ Orchestration & Application Definition ◦ Networking & Policy ◦ Distributed DB & Storage ◦ Streaming & Messaging ◦ Container Registry & Runtime ◦ Software Distribution
  6. Velocity Source: Sysdig 2019 Container Usage Report "[T]he number of

    containers that are alive for 10 seconds or less has doubled to 22%." HOW FAST IS THIS THING GOING???
  7. 73% Velocity Source: Sysdig 2019 Container Usage Report of all

    containers live for thirty minutes OR LESS. HOW FAST IS THIS THING GOING???
  8. WHAT DOES THE DATA TELL US? Velocity Source: 2019 Accelerate

    State of DevOps Report ◦ High performing teams deploy multiple times a day ◦ Lead times are less than a day ◦ Service restorations happen in less than an hour ◦ Change failure rates are between 0-15%
  9. SECURITY MUST BE CONTINUOUS And integrated throughout the IT lifecycle

    Security policy, process & procedures DESIGN BUILD RUN MANAGE ADAPT Identify security requirements & governance models Built-in from the start; not bolted-on Deploy to trusted platforms with enhanced security capabilities Automate systems for security & compliance Revise, update, remediate as the landscape changes
  10. PRIVATE REGISTRY EXTERNAL IMAGES SECURE & AUTOMATE THE CONTENT LIFECYCLE

    Git CONTENT METADATA TRUSTED CONTENT UNKNOWN CONTENT CI CD CD for Security
  11. ◦ Troubleshoot the lowest layers first ◦ Note: Containers are

    made with layers ◦ L3/L4 now lives in YAML files maybe with app configs ◦ L6 is now the output of K8s APIs CD for Security Source: OSI Model https://chrisshort.net/drawings/osi-model/
  12. UNIT TEST CODE QUAL VULN SCAN INT TEST QA UAT

    -Cucumber -Arquillian -Junit -Sonarqube -Fortify -App Scan -Aqua Security -Black Duck -Clair -Sonatype -StackRox -Twistlock OPENSHIFT CI/CD PIPELINE PROMOTE TO PROD ☒ ☑ PROMOTE TO UAT PROMOTE TO TEST IMAGE BUILD & DEPLOY CI/CD MUST INCLUDE SECURITY GATES • Integrate security testing into your build / CI process • Use automated policies to flag builds with issues • Sign your custom container images CD for Security
  13. • Host & Runtime security • Identity and Access Management

    • Role-based Access Controls • Project namespaces • Integrated SDN - Network Policies is default • Integrated & extensible secrets management • Logging, Monitoring, Metrics SECURING THE CONTAINER PLATFORM Security Features Should Include RHEL CoreOS RHEL RHEL CoreOS RHEL RHEL CoreOS
  14. Sources: Kubernetes Documentation Basic and advanced configuration of Security-Enhanced Linux

    (SELinux) Platform Security setenforce 1 has protected organizations from vulnerabilities in upstream Kubernetes SELINUX Not a security feature necessarily, Namespaces are a way to divide cluster resources between multiple users which can minimize blast radius. Namespaces Secure Computing Mode (seccomp) is a kernel feature that allows you to filter system calls to the kernel from a container. Seccomp Control groups account for, control, prioritize, and limit system resource usage (CPU, memory, disk I/O, etc.) Cgroups Pod security policies and network policies can codify business requirements that can be applied cluster wide Security policies
  15. Dependency scanning Platform Security Security touchpoints must be in the

    pipeline. They should be at a minimum enforcing OWASP Proactive Controls. OWASP Top 10 The best place to check for buggy code is in your codebase (not production). Source Code Analysis Tools Static analysis of code at rest Dynamic Application Security Testing (DAST) is a required step in the pipeline. If dependencies have vulns they should be upgraded and tests against new versions should run automatically. Base images should be secure be build with security in mind, used by default, and continuously scanned and patched. Trusted images should be signed on build and verified on pull. Trusted Base Images Integrated registry with scanning capabilities and container health index as a sole source of truth. Trusted Registries Source: OWASP Top 10
  16. Platform Security ◦ Contextually aware ◦ Additional extensibility (CRDs) ◦

    Move at the speed of Kubernetes internals ◦ Robust, scalable, portable controls USE KUBERNETES NATIVE CONTROLS
  17. Source: Cloud-native security for containers and Kubernetes Platform Security ◦

    Network segmentation: Policy enforcing controls ◦ Admission controllers: Enforce policy pre-apply ◦ Infrastructure as Code: More relevant than ever CLEAR BOUNDARIES
  18. Automation KUBERNETES SECURITY OPERATIONS Secure defaults Network isolation Signing and

    policies Audit and logs Multicluster aware Monitoring and alerts Zero-downtime upgrades Full-stack patch & upgrade Vulnerability scanning HARDEN OPERATE AUTOMATED OPERATIONS
  19. Source: Site Reliability Engineering. Ch. 6, Monitoring Distributed Systems Automation

    ◦ Reduce friction and improve experience ◦ Golden Signals (Latency, Traffic, Errors, Saturation) ◦ Compromise will occur; practice disasters ◦ Break things on purpose (Chaos Engineering) RETHINKING RISK & SAFETY
  20. Automation ◦ Scale violating deployments to zero quickly ◦ Auto-patching

    on new dependency releases ◦ Bad actors registered in security policies ◦ Pushing security policies to network edges FUTURE: AUTOMATING MITIGATION
  21. "You are either building a learning organization, or you will

    be losing to someone who is." —Andrew Clay Shafer, Red Hat CONTINUOUS LEARNING
  22. Continuous Learning Encourage co-workers to attend local Meetups with you

    to learn from others in your area. Meetups Attend events like these and talks like this that are near you (not just the huge ones). Events Open source has shown that the more minds working on a problem, the higher the likelihood of the solution being groundbreaking. Community Participation
  23. Many local and national level governments have security operations centers;

    work with them to help inform others Continuous Learning Never underestimate the power of the Google Setup alerts for critical phrases that impact security posture Google Alerts I contribute to two newsletters (KubeWeekly and DevOps’ish) and a podcast (PodCTL), but there are many other fine news sources for relevant information Newsletters, Podcasts, etc. Governments Sharing More Information
  24. linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHat Red Hat is the world’s leading

    provider of enterprise open source software solutions. Award-winning support, training, and consulting services make Red Hat a trusted adviser to the Fortune 500. Thank you