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.

[WSO2Con Asia 2018] Talk Microservices to Me: The Role of IAM in Microservices Architecture

116 views

Published on

This slide deck explores the challenges of securing microservices, best practices to overcome them, and expectation of IAM in the microservices architecture.

Learn more: https://wso2.com/library/conference/2018/08/wso2con-asia-2018-talk-microservices-to-me-the-role-of-iam-in-microservices-architecture/

Published in: Technology
  • Be the first to comment

[WSO2Con Asia 2018] Talk Microservices to Me: The Role of IAM in Microservices Architecture

  1. 1. Technical Lead, WSO2 Talk Microservices to Me: The Role of IAM in Microservices Architecture Darshana Gunawardana
  2. 2. Microservices ● Microservice architecture is about ○ Single application as a collection of small and independent services ● Independent services ○ Developed independently ○ Deployed independently ○ Running independently ● Not just about an architectural pattern ○ Driven by the primary goal  - speed to production
  3. 3. ● All the services are deployed in the same application server ● Few entry points - intercepted and enforced security ● The application server itself provides session management features ○ All the services can share a user’s login status ● The interactions between services are local calls Monolithic Applications
  4. 4. Monolithic Applications + IAM User Session Single Container I n t e r c e p t IAM
  5. 5. Monolithic vs. Microservices User Session Single Container Single Container Single Container Single Container Single Container
  6. 6. Microservices + IAM IAM Single Container Single Container Single Container Single Container
  7. 7. ● Broader attack surface ● Microservices are independent to each other ○ Each service has to enforce authentication, authorization ● Scalability ○ Each service will serve thousands of requests per second ○ There can be hundreds of microservices ● Performance ● Deployment complexities ● Polyglot architecture Challenges
  8. 8. ● Business requirements ○ Strong authentication ○ Merging Acquisitions ○ Social logins ● Capabilities ○ MFA, Adaptive authentication ○ Identity federation ○ Authorization policies ● Access delegation becomes more prominent Current IAMs become obsolete?
  9. 9. Protected resources using OAuth 2.0 Secure endpoints?
  10. 10. OAuth 2.0 Microservices (Resource Server) IAM (Authorization Server) Client Get a token to access the resource on behalf of the resource owner Access the resource Grant access to the client to access a microservices under a provided scope Resource Owner Introspect
  11. 11. OAuth 2.0 - Self Contained Access Tokens IAM (Authorization Server) Microservices (Resource Server) Client Get a token to access the resource on behalf of the resource owner Access the resource Resource Owner Grant access to the client to access a microservices under a provided scope JWT <Trust>
  12. 12. ● Secure development ○ Static, dynamic code analysis ○ Dependency screening ○ Should be part of CICD process ○ Should have shorter feedback cycles ● Secure deployment ○ Service-per-host ○ Container level security ● Secure endpoints ● Service to service security Microservices Security
  13. 13. Secure endpoints
  14. 14. Secure Endpoints IAM (Authorization Server) Microservices (Resource Server) Client Get a token to access the resource on behalf of the resource owner Access the resource Resource Owner Grant access to the client to access a microservices under a provided scope JWT <Trust>
  15. 15. API Gateway Pattern API Gateway Single Container Single Container Single Container Microservice Microservice Microservice
  16. 16. API Gateway Single Container Single Container Microservice Microservice Token Exchange Auths Server 1 2 3 4 5Access Token jwt at OIDC <Trust> <authenticate> <Trust> <Trust>
  17. 17. Service to service security
  18. 18. TLS Mutual Authentication ● Each microservice will have its own certificate to prove its identity ● How do we provision certificates to each microservice? ● How do we deal with certificate revocations? ● How do we deal with trust bootstrap? ● How do we deal with key rotation?
  19. 19. SPIFFE ● Secure Production Identity Framework for Everyone ● SPIFFE tries to solve the trust bootstrap problem in a platform agnostic manner ● SPIFFE provides an identity to each workload in a microservices deployment, which is known as the SPIFFE ID ○ E.g. spiffe://acme.com/billing/payments ● Implementations - SPIRE, Istio
  20. 20. JWT (JSON Web Token) ● Defines a container to transport data between interested parties ● There are multiple applications of JWT ○ In OpenID Connect the id_token is represented as a JWT ● Propagate ○ one’s identity ○ user entitlements between interested parties over a unsecured channel
  21. 21. Self Issued Access Tokens CA Microservice B Microservice A Access the resource JWT <Trust>
  22. 22. Access Control
  23. 23. ● Interoperable JWT for authentication and authorization ● Introduce 2 new claims to the MP-JWT ○ "upn": A human readable claim that uniquely identifies the subject or user principal of the token ○ "groups": The token subject's group memberships ● Enables Role Based Access Control (RBAC) MicroProfile JWT (MP-JWT)
  24. 24. Policy Evaluation (Central PDP) Single Container Single Container Single Container Microservice Microservice Microservice Single Container Microservice Single Container PDP jwt jwt jwt Authz req Authz resp
  25. 25. Policy Evaluation (Embedded PDP) Single Container Single Container Single Container Microservice Microservice Microservice Single Container Microservice jwt jwt jwt PDP PDP PDP PDP PAP <Subscribe> <Subscribe> <Publish Policies>
  26. 26. ● A lightweight general-purpose policy engine that can be co-located with the service ● Can integrate OPA as a sidecar, host-level daemon, or library ● Integrated with Spring, Service Mesh implementations (Istio, Linkerd) Open Policy Agent (OPA) Service OPA Query Decision DataPolicy
  27. 27. Deployment Models
  28. 28. Docker ● Docker is a way to package application or a service ● Abstracts technologies need to run the service to a container ● Run multiple services (container) on the same host machine ○ Different environment to each of them ○ Isolating each other
  29. 29. Kubernetes ● Container orchestration system ○ Abstracts away the hardware infrastructure ○ Deployment as a code ● Allows to easily deploy and manage containerized applications on top of it ● Introduces another level of isolation ○ Pod - A logical grouping of containers that is deployed in the same physical host ○ Communication cost is very low for containers within the pod ○ Enables Sidecar pattern
  30. 30. Kubernetes (Pods) Container Container 1 Container 1 Container 2 Pod 1 IP: 10.1.0.1 Pod 2 IP: 10.1.0.2 Pod 3 IP: 10.1.0.3 Container Container 1 Container 1 Container 2 Pod 4 IP: 10.1.0.4 Pod 5 IP: 10.1.0.2 Pod 6 IP: 10.1.0.3 Container 2 Worker Node 1 Worker Node 2
  31. 31. Security Sidecar Single pod Microservice Security Sidecar Token PDP User-Info Introspection
  32. 32. Security Sidecar - Inbound Single pod Microservice Security Sidecar Introspection PDP
  33. 33. Token Security Sidecar - Outbound Single pod Microservice Security Sidecar User-Info
  34. 34. ● Provide strong access delegation capabilities ● Provide flexible token exchange capabilities ● Support for standard APIs to integrate with security sidecars ● Ability act as a lightweight STS IAMs Role
  35. 35. ● Microservices paradigm introduces new set of challenges to enforce security ● Lots of new trends to enforce edge, channel security in microservices ● API driven strong access delegation capabilities is a MUST for microservices friendly IAM Summary
  36. 36. THANK YOU wso2.com

×