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.

Modern problems in backend engineering, Siim Kaspar Uustalu

72 views

Published on

Modern problems in backend engineering, Siim Kaspar Uustalu

Published in: Software
  • Be the first to comment

  • Be the first to like this

Modern problems in backend engineering, Siim Kaspar Uustalu

  1. 1. Practical authentication and authorization for external facing service mesh applications Siim Kaspar Uustalu Backend team lead
  2. 2. The plan ● Set the scene ● Introduce authentication ● Add authorization on top
  3. 3. whoami ● I’m a software engineer ○ Delivered work for TUNE, the Estonian Road Admin. & others ○ Currently in digital banking ● Mooncascade helps you develop products ○ Trusted by banks, telcos & startups ○ Helps you bridge the hiring gap ○ Does development work across the stack
  4. 4. The scene: application ● Put on your architect hat ○ We’re building math as a service! ○ Service oriented architecture ■ HTTP expression parser + gRPC operation services ○ Containerised w/ k8s for orchestration ● Outsourced operations services
  5. 5. Application architecture
  6. 6. The scene: our mission ● Offer MaaS API ○ Identify users ○ Support authorization levels ● Support application growth ○ Avoid introducing code dependencies ○ Plan for team growth - autonomy matters
  7. 7. Authentication ● The usual scenarios ○ Machine users ○ Backend services as user agents ○ Client side applications ● Solved problem with the OAuth 2.0 framework
  8. 8. Authentication: implementation ● Make use of service mesh facilities ○ Istio: JWT based auth out of the box ■ Signature validation ■ Drawback: not good for user facing applications ● Extend minimally ○ Replace out of box ingress with API gateway ○ Provide OAuth2 service + identity provider ○ Plug an authentication service into the API gateway
  9. 9. Authentication: the API gateway ● Authenticates requests ○ In combination with the authentication service ● Provides routing ● Terminates incoming TLS ○ Mutual TLS in the mesh ● Traefik, Ambassador & friends
  10. 10. Authentication: OAuth2 service ● Does the boring, but important parts ○ Client application management ○ Key management (maybe) ○ The actual protocol ● Integrates with an identity provider ○ That’s you! ● Should be off the shelf
  11. 11. Authentication: auth service ● Verifies issued OAuth token ○ Bridge between API gateway & OAuth2 service ● Issues short-lived internal JWTs ○ These carry requester identity, delegated down request chain ● Provides keys for the service mesh ○ Mesh verifies the signature using the public key
  12. 12. Architecture with authentication
  13. 13. Authorization ● Which actions are permitted given a set of facts? ● Retrofitting affects all services ● Separate domain with own rules in all services ● NB!: Distributed teams ● Idea: Separate the authorization policies from services
  14. 14. Authorization: implementation ● Istio enables policy definition out of the box ○ Based on JWT payload ○ Good enough for basic request control ● Adapters enable more fine-grained control ○ Response, better visibility over rule set ○ Lets roll with the Open Policy Agent adapter
  15. 15. Authorization: Open Policy Agent ● DSL for policy definition - Rego ○ Declarative policy definitions + capable standard library ○ Still testable ● Separate authorization domain per service ● Contract over library approach ○ Right tool for each job
  16. 16. Authentication policy example
  17. 17. Architecture with authorization
  18. 18. Conclusion ● Extended an external facing service to... ○ Support the OAuth2 protocol ○ Support request authentication ○ Provide authorization from a sidecar service ● Made use of Istio facilities where possible
  19. 19. The service mesh pattern enables cleaner separation between features and the “glue” siimkaspar.uustalu@mooncascade.com mooncascade/service-mesh-auth-demo Coming soon!

×