securing the perimeter around your microservices
play

Securing the Perimeter around Your Microservices Wojciech Lesniak - PowerPoint PPT Presentation

Securing the Perimeter around Your Microservices Wojciech Lesniak AUTHOR @voit3k Module Overview Basic Certificates Tokens, JWT Oauth2, OpenID authentication Connect Identity provider Microservices API Gateway Challenges with Edge


  1. Securing the Perimeter around Your Microservices Wojciech Lesniak AUTHOR @voit3k

  2. Module Overview Basic Certificates Tokens, JWT Oauth2, OpenID authentication Connect

  3. Identity provider Microservices API Gateway

  4. Challenges with Edge Security

  5. External API consumers

  6. Type of API Consumer Human (User) Non-human (Service or system)

  7. Authentication / Authorization Authe uthenti nticati tion Autho uthoriza zati tion The process of identifying who the The process of identifying what the consumer is. consumer can do.

  8. Principal of Least Privilege Every user or service consumer has the bare minimum privileges which are essential to perform their tasks.

  9. Principal of Least Privilege Limits the blast radius of any compromise to your system.

  10. Type of API Consumer Human (User) Non-human (Service or system)

  11. Human Users Client Victoria Microservice /victoria

  12. Delegation Problem Can you trust that the client is in-fact acting on behalf of the user and has their consent to do so?

  13. User Clients Proprietary data User data

  14. Delegated Access Authenticate user (resource owner) Get their consent to authorize client access to their resources

  15. Delegated Authorization Victoria Withdraw Delegate Joe

  16. API Gateway: Exposing Your API Securely

  17. Transition to Microservices PORT : 80 PORT : 8080 PORT : 8081 REST HTML REST REST Portfolio Pricing Session Data Data Access Access in-process Support Portfolio PORT : 8082 Pricing Account REST Support Data Access Data Access

  18. Clients Microservices PORT : 8080 REST Portfolio Data PORT : 8081 Access REST Pricing Data Access PORT : 8082 REST Support Data Access

  19. Clients Microservices PORT : 8080 REST API Gateway Portfolio Data PORT : 8081 Access REST Pricing Data Access PORT : 8082 Audit logs REST QOS checks Support Throttling Data DOS prevention Access

  20. Development team can focus more on business requirements rather then non- functional security requirements.

  21. Single Responsibility Principal Each microservice should perform one function and do it well.

  22. Benefits of an API Gateway Avoids the need for shared libraries making our architecture polyglot.

  23. Defensive Structures

  24. Basic- username / password Static API key Client id and client secret OpenID connect SAML Fingerprinting Certificates

  25. Clients API Gateway Firewall API Gateway API Gateway API Gateway MITM

  26. Considering Basic Authentication

  27. Basic Authentication Base64 encoded username:password dXNlcm5hbWU6cGFzc3dvcmQK He Heade der na name me Va Value Authorization Basic dXNlcm5hbWU6cGFzc3dvcmQK

  28. Why Basic Is Not Suitable for Microservices Authentication is more complex then just a username and password, requiring 2 Factor or Multifactor. For persistent login the credentials would have to be stored on the client. In a distributed system, credentials are exposed to multiple services. Delegation can only be done by requesting the users credentials.

  29. Authenticating Clients with Certificates

  30. Clients Microservices PORT : 8080 REST Firewall Portfolio Data API Gateway PORT : 8081 Access REST Pricing Data Access PORT : 8082 REST Support Data Access MITM

  31. At minimum TLS 1.2 or higher

  32. Certificate Authority API Gateway Client mTLS Public / private key, signed by CA Public / private key, signed by CA

  33. Transport Layer Security (TLS) Certificate issuers by CA CA public key, verify server

  34. Challenges with mTLS Does not solve the delegated access or the confused deputy problem. You have to maintain a Public Key Infrastructure and your Certificate Authority. Key provisioning, bootstrapping, and rotation, and invalidating keys can be challenging as the number of clients and services increases.

  35. Introducing Tokens

  36. Clients STS Firewall Authenticate Microservices Portfolio Introspection Support API Gateway Pricing Get resource

  37. Opaque Tokens – by Reference Id:1234567 1234567 Name: Victoria Email: Identity Provider vic@email.com

  38. Bearer T oken A security token with the property that any party in possession of the token (a "bearer") can use the token in the same way that any other party with possession can.

  39. Benefits of Tokens Microservices are never exposed to the users or clients password. “Single responsibility Principal” your microservices development teams don’t need to focus on non-functional security requirements. Tokens can be used to provide delegated authorization.

  40. Identity Provider

  41. Subject – Entity Requesting Access Human Machine Software user like Victoria

  42. Subject Principals Username: victoriaN Username: victoriaN name: Victoria Smith dob: 15/05/1988 Email: vic@send.com Email: vic@send.com Address: 1 Bond st Address: 1 Bond st London London gender: Female gender: Female dob: 15/05/1988 name: Victoria Smith name: Victoria Smith Address: 1 Bond st London gender: Female dob: 15/05/1988

  43. Coupling Application and Identity data API Gateway REST REST Portfolio Support Data Access Data Access Get principal Get principal Get principal sync sync principal principal principal application application

  44. Micros oserv rvices (Ex (Except pt for the or the D Data ta) API Gateway REST REST App data App data Support Portfolio Data Access Data Access Get principal Get principal Get principal principal Monolithic data store

  45. Identity Provider A service that manages the creation, maintenance of identity information for principals.

  46. Authentication as a service (AaaS) Manage and provider single sign in for all users in your applications, systems, and networks centrally.

  47. Clients Identity provider STS Authz Server Firewall Authenticate Microservices Portfolio Verify Support API Gateway Pricing Get resource

  48. Identity Provider Client Victoria Microservices API Gateway /portfolio Portfolio 401 Unauthorized Support Pricing

  49. Relaying Party principal Identity provider LDAP Victoria Client Microservices API Gateway Portfolio /portfolio Support Pricing

  50. Identity Provider Can Become a Bottleneck Identity provider verify

  51. By-value Tokens

  52. By-value Token username: victoria name: Victoria Lesniak Derpartment: reserch

  53. Claims-based identity Claims define what the subject is and is not.

  54. By-value Token Identity provider principal username: victoria name: Victoria Lesniak derpartment: reserch LDAP Signed with providers private key

  55. A signed token without the expiration date is worse than a password.

  56. What format should your by-value token be?

  57. Answer A standard token format.

  58. Different Token Formats Introduce Complexity

  59. Evolution of Security Tokens 1990s 2015 Kerberos JWT Protocol agnostic Protocol specific 2002 SAML Protocol specific

  60. Evolution of Security Tokens 1990s 2015 Kerberos JWT Protocol agnostic Protocol specific 2002 SAML Protocol specific

  61. Evolution of Security Tokens 1990s 2015 Kerberos JWT Protocol agnostic Protocol specific 2002 SAML Protocol specific

  62. JSON Web Token (JWT)

  63. JWT Optional Standard Claims Cla laim im Desc scripti ption jti Unique token identifier iss Issuer – who issued the token sub Subject – Who the claims represent. aud Audience – The recipient the token was meant for. exp Expiration – Until when the token is valid iat Issued at – The time the token was issued.

  64. JWTs can also be encrypted to prevent the content being read by unwanted parties, using the JSON Web Encryption (JWE) specification.

  65. Javascript Object Signing and Encryption (JOSE) JSON Web Token (JWT) (JWS) JSON Web Signature (JWE) JSON Web Encryption (JWA) JSON Web Algorithm

  66. Delegated Authorization with OAuth2

  67. Open Authorization (OAuth2) OAuth2 is an open standard used to allow entities to grant limited access to their resources, without sharing their credentials.

  68. Actors in OAuth Authorization server Resource server Client Issues access token to client protects Resource Owner Protected resource owns

  69. OAuth2 Authorization Code Grant User Client 1. Sign-in Crypto Portfolio Victoria 2. Redirect to auth-server <client id> 7. Forward auth code https/ /auth-server-uri/ 11. /portfolio https/ / crypto-portfolio-redirect-uri /?code=123456&state=987654 Browser client id ?client_id=crypto-portfolio&scope=profile,portfolio&response_type=code secret http POST: &redirect_uri=crypto-portfolio-uri&state=987654 Crypto Portfolio code:123456 would like to access client_id: crypto-portfolio your profile and portfolio data. client_secret: secret Approve Resource Server Authorization server client id secret

  70. Other Grant Types Client credentials

  71. Sign-in with OAuth2

  72. The Reasons for OpenID Connect

  73. OAuth2 is for delegated authorization and not designed for authentication.

  74. User Clients Proprietary data User data

Recommend


More recommend