The Top 10 List of Istio Security Risks and Mitigation Strategies

CNCF is developing its first ever Top 10 list of security risks facing Istio deployments. As a community-driven effort, it draws on the expertise of a wide range of security professionals and cloud native computing experts to ensure the list reflects the most current and relevant security risks facing cloud native applications.

Transcript

1. TOP TEN ISTIO SECURITY RISKS AND MITIGATION STRATEGIES NDC { Security }
2. SOFTWARE ENGINEER @ TETRATE José Carlos Chávez • Peruvian • Open source enthusiast • OWASP Coraza Co-leader • Mathematician in quarantine @jcchavezs NDC { Security }
3. SECURITY RISKS AND MITIGATION STRATEGIES MITIGATION STRATEGIES: Dealing with risks 1. assume and accept risk 2. avoidance of risk 3. controlling risk 4. transference of risk 5. watch and monitor risk SECURITY RISKS: Likelihood + Impact • how easy is to carry out an attack? How skilled should be the attacker? • how cheap it is to launch attacks? • how sensitive are the systems likely to be affected, how valuable and sensitive is the target data? is it hard to recover the data? @jcchavezs NDC { Security }
4. “ Isn’t Istio secure by default? @jcchavezs NDC { Security }
6. 7 LAYERS OF CLOUD SECURITY (DEFENSE IN DEPTH) • L1: Policies, procedures and awareness for a culture of strict data security • L2: Physical security to protect data and devices • L3: Perimeter defense to balk initial attacks and discourage further attempts. • L4: Internal network security to protect critical systems and data. • L5: Host security to avoid backdoors • L6: Application security to avoid exploits • L7: Data security to protect the most important thing @jcchavezs NDC { Security }
7. These building blocks span different layers of security, sometimes overlap one with another but all of them must be secured. Istio deployment building blocks Underlying infrastructure Kubernetes platform Istio service mesh Applications @jcchavezs NDC { Security }
8. “ But who should I protect my system from? @jcchavezs NDC { Security }
9. THREAT ACTORS INTERNAL ATTACKER An entity with some level of privilege that would seek to exceed one or more trust boundaries. CONTRIBUTORS TO ISTIO Contributors could harm Istio by attempting to intentionally introduce vulnerable code and subsequently exploit it. CONTRIBUTORS TO 3RD-PARTY DEPS Istio's dependencies may be used by malicious attackers to exceed their trust boundaries. UNTRUSTED USERS Users with the lowest level of privilege that may seek to cause harm by exceeding their trust boundaries. 9 @jcchavezs NDC { Security }
10. “ What is the risks then? Where does this list come from? @jcchavezs NDC { Security }
11. I01: INSECURE COMMUNICATION Significant security threat: on-path attacks, spoofing, credential stuffing, brute force, etc. • The Istio permissive security setting is useful but insecure as it accepts plaintext and encrypted traffic. • A strict security setting would force all communication to be secure Mitigation: • Enable mTLS through a PeerAuthentication policy on namespace or wide mesh (istio-system namespace). • If permissive mode is required, restrict it with an AuthorizationPolicy to specific resources. • Configure TLS verification using a DestinationRule when originating TLS in the sidecar. @jcchavezs NDC { Security }
12. I02: UNSAFE AUTHORIZATION PATTERNS Istio allows fine-grained authz policies for traffic between workloads using the AuthorizationPolicy ... spec: action: ALLOW rules: - to: - operation: notPaths: ["/private"] Mitigation • Use default-deny patterns: your system denies all requests by default • Use ALLOW-with-positive-matching and DENY-with-negative-match patterns @jcchavezs NDC { Security }
13. I03: WEAK SERVICE ACCOUNT AUTHN @jcchavezs One of the most important principles of cyber security is the least privilege principle: A subject should have no more access privileges than what is necessary for their task. • init_container has permissions to create network policies • Bypass outboundTrafficPolicy by impersonating the istio-proxy user (UID 1337) • Usage of first-party-jwt (no audience specified). Mitigation - Use Istio CNI plugin to avoid requiring privileges like NET_ADMIN capability. - Require containers inside pods to run as non root using MustRunAsNonRoot - Use third-party-jwt to restrict its usage to sidecar NDC { Security }
14. I04: BROKEN OBJECT LEVEL AUTHZ (BOLA) Istio provides AuthorizationPolicy to perform checks on HTTP headers and the path, Kubernetes metadata (origin and destination services) as well as validating JWTs. • Cannot access to all JWT’s fields (lack of metadata) • Policies get out of sync with architecture Mitigation • All access decisions have to be based on least-privilege principles, per-request, context-based, and on identities. • Use rich model policies like NGAC or OPA for declarative, domain-compatible policies. @jcchavezs NDC { Security }
15. I05: SUPPLY CHAIN VULNERABILITIES Istio itself uses several open-source components and third-party code (e.g. Envoy, Prometheus, etc) but a typical Istio deployment includes several images from different sources. Some of the risk are: • Image Integrity • Image Composition • Known Software Vulnerabilities Mitigation • Image scanning & curated registry. • Software Bill of Materials (SBOM). • Image Signing. • Curated registry. • Web Application Firewall to patch vulnerabilities. @jcchavezs NDC { Security }
16. I06: INGRESS TRAFFIC CAPTURE LIMITATIONS Istio sidecar is supposed to hook inbound and outbound traffic in the pod, however: • It does not support UDP traffic, so traffic will be passed to services inside the Pod. • Inbound capture is disabled on ports used by the sidecar (including port 22) Mitigation • For control of UDP traffic, use Kubernetes NetworkPolicy at ingress. @jcchavezs NDC { Security }
17. I07: EGRESS TRAFFIC CAPTURE LIMITATIONS Istio cannot securely enforce that all egress traffic flows through the egress gateways i.e. it can not enforce calls to be done to known destinations e.g. outboundTrafficPolicy: REGISTRY_ONLY does not prevent access to undeclared services. Mitigation • Kubernetes NetworkPolicy for egress. • Runtime checks on linux system calls (e.g. falco) • Anomaly detection on outbound traffic. @jcchavezs NDC { Security }
18. I08: SECURITY OBSERVABILITY AND MONITORING FAILURES Security observability and monitoring are critical components, however, incorrect collection, processing or reporting of such data can pose significant risks to the security. • Log level paradox • Insufficient or inadequate audit logs • Lack of context, broken correlation Mitigation • Ensure access logs and error logs are emitted. • Implement a org-wide log format. • Log data should be encoded/redacted correctly. • Ensure high-value transactions have an audit trail e.g. using distributed tracing. @jcchavezs NDC { Security }
19. I09: VULNERABLE ISTIO VERSIONS Older versions may contain known vulnerabilities that have been addressed in later versions. Some of the disclosed attacks are: • (DoS) attacks • CVEs • Bypass of Istio policies • Cryptographic Mitigation • Use compliant Istio distributions e.g. Tetrate Istio Distro • Track CVE databases and Istio Security Bulletins. • Web Application Firewall to network vulnerabilities. @jcchavezs NDC { Security }
20. I10: LACK OF INCIDENT RESPONSE AND RECOVERY PLAN Incident Response (IR) in service mesh is more complicated than classical IR due lack of physical access, accelerated deployment life cycles, diffuse perimeter and lack of observability. Being proactive about anomalous behaviours is crucial to run effective incident response. Mitigation • Proactive observability with signals analysis and anomaly detection. • Ability to do fine grained access policies for reach mitigation. • Web Application Firewall for containing attacks. • Mechanism to rotate credentials on demand. • Redundancy of core components for degraded service. @jcchavezs NDC { Security }
21. CONSEQUENCES OF SECURITY INCIDENTS @jcchavezs NDC { Security } Source: Venafi - The Impact of Machine Identities on the State of Cloud Native Security in 2023
22. CONCLUSIONS • Most of the security risks are related to configuration: mistakes, naive and non deterministic security policies, etc. • Always prefer explicit over relying on defaults or “auto” capabilities. • No single component or function will be sufficient to achieve a good level of security alone, but collectively they need to enforce security patterns across all layers in the infrastructure. • Policies have to be defined based on the assumption that the attacker is already inside the network. @jcchavezs NDC { Security }
23. For any further queries, feel free to contact me at jc@tetrate.io Thank you everyone. jcchavezs jcchavezs www.tetrate.io
24. References The Impact of Machine Identities on the State of Cloud Native Security in 2023 - Venafi Sysdig 2023 Cloud‑Native Security and Usage Report https://sysdig.com/blog/2023-cloud-native-security-usage-report/ NIST SP 800-207A: A Zero Trust Architecture (ZTA) Model for Access Control in Cloud Native Applications in Multi-Location Environments State of Service Mesh Market 2022 - Tetrate https://tetrate.io/tetrate-service-mesh-survey-2022/ https://venafi.com/lp/cloud-native-security-report-2023/ @jcchavezs NDC { Security }
25. References 2022 Service Mesh Adoption Survey State of Kubernetes security report - Redhat, 2022 https://www.redhat.com/en/resources/state-kubernetes-security-report https://www.solo.io/resources/report/2022-service-mesh-adoption-survey/ @jcchavezs Istio Security Audit - Ada Logics 2022 https://istio.io/latest/blog/2023/ada-logics-security-assessment/ NDC { Security }
26. TOP TEN ISTIO SECURITY RISKS AND MITIGATION STRATEGIES NDC { Security }