NICK SMITH Many new and existing systems are built using Microservices. As the number of deployed Microservices increases the complexity in security grows. The addition of multiple autonomous teams further increases the attack surface of a system as more services are pushed into production. Finally the business need to deploy 3rd-party services with “soft” security guarantees must be addressed. As a result maintaining system integrity becomes a significant challenge and one that must be managed. To mitigate some of the risks we present a background on the three A’s (Authentication, Authorization and Accounting) of computer security explaining each in detail and their importance from a broad system perspective. From there we take the audience through a set of Microservice-native patterns and tools for enforcing and managing each `A` with a focus on enforcement and measurement at the service mesh layer. At the conclusion of the talk attendees should have a greater understanding of how to apply system-level security patterns to their Microservice architecture, tools to use to implement the learnt patterns and so improving their security posture.

1. LONDON 18-19 OCT 2018
Patterns and techniques for
securing Microservices
NICK SMITH
THALES ESECURITY
ISTIO SECURITY WG

2. LONDON 18-19 OCT 2018
Warning: This talk does not deal with Ag projectiles
• Tools discussed can help but not solve all your woes.

3. LONDON 18-19 OCT 2018
Microservices primer
• Microservices: A software system that has been separated into smaller
modules that interact with each other.
• Self-contained, a microservice stands alone.
• Dynamically deployed often via Containers on a platform such as
Kubernetes.
• An architecture suited to cooperating autonomous teams.

4. LONDON 18-19 OCT 2018
So what’s the problem? A problem shared …
• Holistic system security is hard – how do we reason about our system?
• Mo microservices, mo problems – We’ve gone from a monolith to a maze.
• Multiple autonomous teams - Everyone is doing things differently.
• How do we perform static analysis across service interactions?

5. LONDON 18-19 OCT 2018
Facebook “View As” exploit as an example
• 3 bugs.
• Complex interaction of different components.
• Hard to mitigate without a holistic system view.
• Holistic system views are hard to achieve without security being seen as
a blocker and “mitigator of progress”.
• We must use tools!
• This is why DevSecOps is cool!

6. LONDON 18-19 OCT 2018
Authentication, Authorization and Accounting
• Authentication: the identification of unique users; human or otherwise
• Authorization: Who *can* do what, when and why
• Accounting: Who *did* what, when and why
• How can a service mesh such as istio.io help?

7. LONDON 18-19 OCT 2018
Reference: A mesh-less deployment

8. LONDON 18-19 OCT 2018
The service mesh to the rescue*!

9. LONDON 18-19 OCT 2018
istio Architecture

10. LONDON 18-19 OCT 2018
Authentication
• Services use unique identifiers,
shared secrets and public keys.
• Services authenticate using OAuth2
Confidential Client flows or mutual
TLS.
• Humans authenticate using unique
identifiers, passwords and ideally
second factors.
• Humans authenticate using SAML
and OpenID Connect flows.
• Both humans and services should authenticate to enable robust access control.
• Authentication is the proof of identity in exchange for a cryptographic assertion
often in the form of a JSON Web Token (JWT) .

11. LONDON 18-19 OCT 2018
Pattern: Transparent Authentication
• User issues a request to a service.
• The service mesh enforcement point checks the
request against the authentication policy and
whether an Identity Token (JWT) is present.
• The service mesh enforcement point redirects
the user to an authentication service using
OpenID Connect authorization flow.
• User authenticates and tries to access the service
again armed with a JWT.
• The service mesh enforcement point allows the
request to proceed after validating the
authentication policy and identity token.

12. LONDON 18-19 OCT 2018
Authorization
• Authorization: the act of allowing or disallowing an operation to be performed
given some contextual information.
• Can <identity> perform <request> given the context <time, policy, other>
• Can <identity> perform <request> given the context <time, policy, other> and
via the intermediate service <identity>
• Authorization can be explicit like in the OAuth2 model:
• Requester requests an Authorization token asserting access rights later presented to the
operating service.
• Authorization can be Just-in-Time:
• Given some contextual information such as identity and time, does the operating service
allow the operation being requested by the requester.

13. LONDON 18-19 OCT 2018
Pattern: Explicit Authorization using OAuth2-like model
• User requests an access token from an
Authorization service.
• Given some contextual information such as
identity (from an Identity Token), time and
policy the Authorization service produces an
Access Token that includes a digitally signed
set of claims describing access rights.
• User includes their Access Token in their
request to a service.
• The service mesh enforcement point
validates the validity of the Access Token and
whether it grants the requester access to the
service and API being requested.

14. LONDON 18-19 OCT 2018
Pattern: Just-in-Time Authorization
• User issues a request to a service
including an Identity Token.
• Given some contextual information
such as identity, time and policy
the service mesh enforcement
point validates whether the
request can be executed.
• The service mesh enforcement
point allows or rejects the request.

15. LONDON 18-19 OCT 2018
Comparison
• Explicit authorization is useful for managing access control using an
external service.
• Think github as the authorization service for ${CI-VENDOR-OF-YOUR-CHOICE}.
• JiT authorization is useful in more dynamic contexts where authorization
decisions cannot always be made upfront. For example, an internal
service in a microservice deployment.
• Both are valid approaches
• Choices are always contextual and security is not a binary operator.

16. LONDON 18-19 OCT 2018
Accounting
• Accounting: the measurement of who has done what on behalf of whom
and why 
• <identity> performed <request> on behalf of <identity> given the context
<time, policy, other>
• Solid accounting is often missing in many systems.
• Useful for understanding system interactions and “good” or “bad” behaviour.
• Observability.
• Accounting can be used in a feedback loop with ML to enhance
authorization decisions!

17. LONDON 18-19 OCT 2018
Pattern: Transparent Accounting
• User issues a request to a service including
an Identity Token.
• Given some contextual information such as
identity, time and policy the service mesh
enforcement point validates whether the
request can be executed.
• The service mesh enforcement point
appends to the accounting record it’s
decision
• The service mesh enforcement point allows
or rejects the request.

18. LONDON 18-19 OCT 2018
Configuring the mesh: Security Configuration-as-Code
• istio.io is configured by code
• Reviewable
• Grok-able
• Manageable
• Parse-able/tool-able
• By using Config-as-Code autonomous teams both define and document
the systems behaviour in one step.
• Observability and thus security reasoning can be improved at the macro
level.

19. LONDON 18-19 OCT 2018
Yaml, all things

20. LONDON 18-19 OCT 2018
EOF
• The move towards microservices and autonomous teams presents a
security conundrum.
• Holistic security view impaired.
• System understanding difficult.
• A service mesh can help to transparently enforce cross-service patterns to
normalize:
• Authentication, Authorization and Accounting
• Security Config-as-Code allows for security enforcement to be reviewed
observed and understood.

21. LONDON 18-19 OCT 2018
nick.a.smith@thales-esecurity.com
https://www.linkedin.com/in/nick-a-smith
twitter and github @nickrmc83
https://istio.io
https://groups.google.com/forum/#!forum/istio-security
https://thenounproject.com