Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Security for cloud native workloads

•Download as PPTX, PDF•
•
Runcy Oommen
Runcy Oommen

Runcy Oommen discusses security for cloud native workloads and containers. Some key points include: 1) The shared responsibility model where cloud providers and customers both have responsibilities for security. 2) Securing the container lifecycle from build to deploy to run through measures like limiting access, resource management, and network segmentation. 3) Kubernetes security improvements such as disabling anonymous authentication, configuring admission controllers, pod security policies, enabling RBAC, and using network policies.

Related slideshows

Managed Threat Detection & Response for AWS Applications
Managed Threat Detection & Response for AWS ApplicationsManaged Threat Detection & Response for AWS Applications
Managed Threat Detection & Response for AWS Applications
 
Extending Amazon GuardDuty with Cloud Insight Essentials
Extending Amazon GuardDuty with Cloud Insight Essentials Extending Amazon GuardDuty with Cloud Insight Essentials
Extending Amazon GuardDuty with Cloud Insight Essentials
 
Extending Amazon GuardDuty with Cloud Insight Essentials
Extending Amazon GuardDuty with Cloud Insight Essentials Extending Amazon GuardDuty with Cloud Insight Essentials
Extending Amazon GuardDuty with Cloud Insight Essentials
 
1 of 36
Security for Cloud Native Workloads 22-May-2021 | DevSecOps Conf 2020 Runcy Oommen
|In brief| Generic cloud native & cloud security overview Shared responsibility model Microservices security Containers v/s Serverless Securing the container lifecycle Kubernetes security improvements
Career  Principal SDE, SONICWALL, 18+ yrs. industry experience primarily in systems, cloud (private/public), security, networking  10x multi-cloud certified (GCP, AWS, Azure, CNCF)  Patent (India) in cloud security around distributed data storage  Interested in serverless, containers and cloud native offerings. Firm believer of a multi-hybrid cloud future Community  Organizer of GDG Cloud, AWS user Group and Cloud Native meetup groups in Bangalore  Regular speaker at domestic and international cloud, tech & security conferences  Multiple hackathon wins in cloud/security topics.  Recognized by Google as a community influencer [~]$ whoami runcyoommen https://runcy.me
What does “Cloud Native” mean? A cloud computing approach to build & run scalable apps in modern environments such as public, private and hybrid clouds. Technologies such as containers, microservices, serverless and immutable infrastructure, deployed are elements of this architecture. Reference: https://en.wikipedia.org/wiki/Cloud_native_computin
IT infrastructure & landscape has undergone a paradigm shift…
Traditional view runcyoommen
Modern view PaaS
So, how exactly should cloud native security differ from traditional network security?
Ubiquitous The cloud is always reachable from anywhere, any time, any device Scalable You can add new features and support users without breaking a sweat Integrated Security and other services talk to each other for full visibility Comprehensive The Cloud scans every byte – ingress and egress – including SSL & CDN Intelligent The cloud learns from every user, network and traffic Important facets of cloud Available Capabilities can be guaranteed to remain accessible runcyoommen
Cloud Features v/s Security Balances  Agility  Self service  Scale  Automation  Gatekeeper  Standards  Control  Centralized  Pay as you go  Timely alerts
Shared Responsibility Model
MONOLITH M-I-C-R-O-S-E-R-V-I-C-E-S Let’s begin the journey… from to
Security for cloud native workloads
Security for cloud native workloads
VM Container
Security for cloud native workloads
 Portability – By abstracting applications from host, it’s easier to run on any platform or cloud  Scalability – Containerized applications holds the ability to handle increasing workloads  Fast Development – Allows developers to change and track changes in the platform’s source code ensuring high productivity  Security – App isolation ensures that separate containers run independently  Continuity – Failure of one will not influence the state of others  Easy Management – Orchestration performs application management, automated installation and workload management runcyoommen
Security for cloud native workloads
Security for cloud native workloads
How did we get here?
Security for cloud native workloads
The stack of *SECURITY* responsibilities… Sys Admin DevOps Develope r
SECURING THE CONTAINER LIFECYCLE BUILD SHIP DEPLOY RUN Image Quality, Exposure Risk Trust, Integrity Assurance Resource, Access Control Process, Network, Secrets VISIBILITY ►Risk posture of the images is not completely understood ►Unclear as to where security should fit in the process ►Containers are not visible with current security tools ►Reliance on open source and external components used
SECURITY STARTS IN THE BUNDLE PHASE BUILD SHIP DEPLOY RUN • Make sure base images are secure • Scan for vulnerabilities on the finished product • Maintain configuration standards • Share info between Dev, Ops, Sec
ADD ENFORCEMENT OF IMAGE USAGE BUILD SHIP DEPLOY RUN • Deny unknown images or registries • Accept images based on risk • Maintain integrity of images
LIMIT ACCESS TO CONTAINER ENGINE BUILD SHIP DEPLOY RUN • Separate automation from human actions • Control parameters that elevate privilege • Permissions on volumes, network etc… • Maintain audit trail with accountable user
GRANULAR RUNNING OF CONTAINERS BUILD SHIP DEPLOY RUN • Resource management • Protect sensitive data • Network segmentation • Fine-grained app controls
Let’s summarize container security • Prevent unknown images Production Host • Stop user privilege escalation • Stop suspicious processes • Enforce network isolation • Encrypt sensitive vars/params • Swear by automation and tools • Visibility across the environment runcyoomme
KUBERNETES SECURITY IMPROVEMENTS Disable Anonymous Authentication Configure Admission Controllers Pod Security Policies Enable Authz with RBAC Network Policies for Segmentation
• Disable anonymous authentication Generally two types of users exist: – Normal Users (managed by outside entities like LDAP, AD etc.) – Service Accounts (managed by K8s API with credentials as secrets) Anything else is treated as anonymous request – Given a username system:anonymous and group system:unauthenticated For e.g. with token authentication & anonymous access enabled, a request with an invalid bearer token would receive a 401 error; a request providing no bearer token would be treated as an anonymous request. Recommendation: Disable this mode by passing --anonymous-auth=false option to API server
• Configure admission controllers – Intercepts requests to create, delete, modify or connect to proxy – “validating” or “mutating” (able to modify the object they admit) Syntax: Replace what appears after = with name of the admission controller --enable-admission-plugins=NameOfController,NameOfController2 Recommendation: * Enable below admission controllers by default LimitRanger,DefaultStorageClass,DefaultTolerationSeconds,Names paceLifecycle,ServiceAccount,MutatingAdmissionWebhook,Validati ngAdmissionWebhook,Priority,ResourceQuota,PodSecurityPolicy * Enable ValidatingAdmissionWebhook to validate K8s resources during create, update, and delete operations * Ensure AlwaysPullImages is set to make sure private images are only pulled by those who have the credentials.
• Disable public access to cluster • Pod security policies – Defined as a cluster level resource that controls security sensitive aspects – Conditions for pod to be admitted in system – Target pod’s service account must be authorized for this policy – Implemented as an optional (but recommended) admission controller – Never expose remote connectivity to your nodecluster – Use a bastion host in your management VPC – Ensure it is peered with the cluster network for connectivity
• Enable authorization with RBAC – Method of regulating access to resources based on the roles of individual users – RBAC uses the rbac.authorization.k8s.io API group to drive authz decisions Syntax: Start the API server with the authorization-mode flag for RBAC kube-apiserver --authorization-mode=RBAC Potential Mistakes: – Make sure cluster-admin role is not granted unnecessarily (especially during the transition from legacy ABAC controller to RBAC) – Role aggregation (K8s v1.9), if not carefully reviewed can lead to improper usage – Duplicated role grant may happen; subjects get same access in more than one way – Unused roles to subjects that do not exist (deleted service accounts) can make it difficult to see configurations that do matter.
• Network policies for segmentation – Specification of how groups of pods can communicate with each other and other network endpoints – When no network policies are applied, then all connections to and from it are permitted – Notion of “pod isolation” which means that pods are isolated if at least one network policy applies to them – Intricate and difficult to understand for proper usage. Network plugins recommended from Calico, Cilium, Kube-router, Romana and Weave Net
Conclusion  Think security early and anticipate for future growth. Honestly, it’s nothing but a mindset!  Focus on logical and organizational structure to engrave it into your environment  Enablement to move fast and break things but protect from themselves  Apply security controls at the layers that make the most sense  Security is no longer about a “layer on top”. Ensure it at every step of the SDLC and throughout the stack
Questions | Comments | Discussions runcyoommen https://runcy.me Runcy Oommen

More Related Content

Security for cloud native workloads

  • 1. Security for Cloud Native Workloads 22-May-2021 | DevSecOps Conf 2020 Runcy Oommen
  • 2. |In brief| Generic cloud native & cloud security overview Shared responsibility model Microservices security Containers v/s Serverless Securing the container lifecycle Kubernetes security improvements
  • 3. Career  Principal SDE, SONICWALL, 18+ yrs. industry experience primarily in systems, cloud (private/public), security, networking  10x multi-cloud certified (GCP, AWS, Azure, CNCF)  Patent (India) in cloud security around distributed data storage  Interested in serverless, containers and cloud native offerings. Firm believer of a multi-hybrid cloud future Community  Organizer of GDG Cloud, AWS user Group and Cloud Native meetup groups in Bangalore  Regular speaker at domestic and international cloud, tech & security conferences  Multiple hackathon wins in cloud/security topics.  Recognized by Google as a community influencer [~]$ whoami runcyoommen https://runcy.me
  • 4. What does “Cloud Native” mean? A cloud computing approach to build & run scalable apps in modern environments such as public, private and hybrid clouds. Technologies such as containers, microservices, serverless and immutable infrastructure, deployed are elements of this architecture. Reference: https://en.wikipedia.org/wiki/Cloud_native_computin
  • 5. IT infrastructure & landscape has undergone a paradigm shift…
  • 8. So, how exactly should cloud native security differ from traditional network security?
  • 9. Ubiquitous The cloud is always reachable from anywhere, any time, any device Scalable You can add new features and support users without breaking a sweat Integrated Security and other services talk to each other for full visibility Comprehensive The Cloud scans every byte – ingress and egress – including SSL & CDN Intelligent The cloud learns from every user, network and traffic Important facets of cloud Available Capabilities can be guaranteed to remain accessible runcyoommen
  • 10. Cloud Features v/s Security Balances  Agility  Self service  Scale  Automation  Gatekeeper  Standards  Control  Centralized  Pay as you go  Timely alerts
  • 17.  Portability – By abstracting applications from host, it’s easier to run on any platform or cloud  Scalability – Containerized applications holds the ability to handle increasing workloads  Fast Development – Allows developers to change and track changes in the platform’s source code ensuring high productivity  Security – App isolation ensures that separate containers run independently  Continuity – Failure of one will not influence the state of others  Easy Management – Orchestration performs application management, automated installation and workload management runcyoommen
  • 20. How did we get here?
  • 22. The stack of *SECURITY* responsibilities… Sys Admin DevOps Develope r
  • 23. SECURING THE CONTAINER LIFECYCLE BUILD SHIP DEPLOY RUN Image Quality, Exposure Risk Trust, Integrity Assurance Resource, Access Control Process, Network, Secrets VISIBILITY ►Risk posture of the images is not completely understood ►Unclear as to where security should fit in the process ►Containers are not visible with current security tools ►Reliance on open source and external components used
  • 24. SECURITY STARTS IN THE BUNDLE PHASE BUILD SHIP DEPLOY RUN • Make sure base images are secure • Scan for vulnerabilities on the finished product • Maintain configuration standards • Share info between Dev, Ops, Sec
  • 25. ADD ENFORCEMENT OF IMAGE USAGE BUILD SHIP DEPLOY RUN • Deny unknown images or registries • Accept images based on risk • Maintain integrity of images
  • 26. LIMIT ACCESS TO CONTAINER ENGINE BUILD SHIP DEPLOY RUN • Separate automation from human actions • Control parameters that elevate privilege • Permissions on volumes, network etc… • Maintain audit trail with accountable user
  • 27. GRANULAR RUNNING OF CONTAINERS BUILD SHIP DEPLOY RUN • Resource management • Protect sensitive data • Network segmentation • Fine-grained app controls
  • 28. Let’s summarize container security • Prevent unknown images Production Host • Stop user privilege escalation • Stop suspicious processes • Enforce network isolation • Encrypt sensitive vars/params • Swear by automation and tools • Visibility across the environment runcyoomme
  • 29. KUBERNETES SECURITY IMPROVEMENTS Disable Anonymous Authentication Configure Admission Controllers Pod Security Policies Enable Authz with RBAC Network Policies for Segmentation
  • 30. • Disable anonymous authentication Generally two types of users exist: – Normal Users (managed by outside entities like LDAP, AD etc.) – Service Accounts (managed by K8s API with credentials as secrets) Anything else is treated as anonymous request – Given a username system:anonymous and group system:unauthenticated For e.g. with token authentication & anonymous access enabled, a request with an invalid bearer token would receive a 401 error; a request providing no bearer token would be treated as an anonymous request. Recommendation: Disable this mode by passing --anonymous-auth=false option to API server
  • 31. • Configure admission controllers – Intercepts requests to create, delete, modify or connect to proxy – “validating” or “mutating” (able to modify the object they admit) Syntax: Replace what appears after = with name of the admission controller --enable-admission-plugins=NameOfController,NameOfController2 Recommendation: * Enable below admission controllers by default LimitRanger,DefaultStorageClass,DefaultTolerationSeconds,Names paceLifecycle,ServiceAccount,MutatingAdmissionWebhook,Validati ngAdmissionWebhook,Priority,ResourceQuota,PodSecurityPolicy * Enable ValidatingAdmissionWebhook to validate K8s resources during create, update, and delete operations * Ensure AlwaysPullImages is set to make sure private images are only pulled by those who have the credentials.
  • 32. • Disable public access to cluster • Pod security policies – Defined as a cluster level resource that controls security sensitive aspects – Conditions for pod to be admitted in system – Target pod’s service account must be authorized for this policy – Implemented as an optional (but recommended) admission controller – Never expose remote connectivity to your nodecluster – Use a bastion host in your management VPC – Ensure it is peered with the cluster network for connectivity
  • 33. • Enable authorization with RBAC – Method of regulating access to resources based on the roles of individual users – RBAC uses the rbac.authorization.k8s.io API group to drive authz decisions Syntax: Start the API server with the authorization-mode flag for RBAC kube-apiserver --authorization-mode=RBAC Potential Mistakes: – Make sure cluster-admin role is not granted unnecessarily (especially during the transition from legacy ABAC controller to RBAC) – Role aggregation (K8s v1.9), if not carefully reviewed can lead to improper usage – Duplicated role grant may happen; subjects get same access in more than one way – Unused roles to subjects that do not exist (deleted service accounts) can make it difficult to see configurations that do matter.
  • 34. • Network policies for segmentation – Specification of how groups of pods can communicate with each other and other network endpoints – When no network policies are applied, then all connections to and from it are permitted – Notion of “pod isolation” which means that pods are isolated if at least one network policy applies to them – Intricate and difficult to understand for proper usage. Network plugins recommended from Calico, Cilium, Kube-router, Romana and Weave Net
  • 35. Conclusion  Think security early and anticipate for future growth. Honestly, it’s nothing but a mindset!  Focus on logical and organizational structure to engrave it into your environment  Enablement to move fast and break things but protect from themselves  Apply security controls at the layers that make the most sense  Security is no longer about a “layer on top”. Ensure it at every step of the SDLC and throughout the stack
  • 36. Questions | Comments | Discussions runcyoommen https://runcy.me Runcy Oommen