Every microservice in production must be secured. In order to ensure this, there is a significant additional effort compared to a monolithic system due to the high number of services. If the operation then still takes place in a public cloud, neither the communication within the infrastructure of the cloud provider nor the connection via the Internet may be unencrypted. In addition, corresponding authorization checks must take place in each individual service. This session shows how easy and effortless it is to implement security measures with a service mesh tool like Istio. With a few small Istio rules, all communication in the service mesh is secured with mutual TLS (mTLS). Basic checks of service-to-service communication and end-user authorization using JWT can also be delegated to Istio. The extended authorization checks within a Java service are illustrated using the MicroProfile specifications.

1. The Easy Way
To
Secure Microservices
Michael Hofmann
Hofmann IT-Consulting
info@hofmann-itconsulting.de
https://hofmann-itconsulting.de

2. Microservices and Security
●
High number of services
●
Every service has to be secured
●
The more services the higher the risk of security
breaches
●
New vulnerabilities (CVE) must be fixed timely in
every service
●
Malicious actor has more endpoints to exploit

3. Consequence: Zero Trust
●
Do not trust anyone or service, even inside a
trust zone
●
Every request has to be authenticated,
authorized and secured (TLS)
●
JWT: E2E Token or TokenExchangeService
●
On (every) multiple network layers

4. Securing Microservices
●
AuthN and AuthZ on every request
●
TLS for every communication between services
– Certificate management for many services
– High degree of automation necessary
– Missing automation: TLS termination on Ingress, no TLS
inside K8S cluster (typical)
●
Is there a one size fits all solution?

5. OWASP (Open Web Application Security Project)
●
Defense in Depth (Layered Defense)
●
Fail Safe
●
Least Privilege
●
Separation of Duties
●
Economy of Mechanism (Keep it
Simple, Stupid KISS)
●
Complete Mediation
https://github.com/OWASP/DevGuide/blob/master/02-Design/01-Principles%20of%20Security%20Engineering.md
●
Open Design
●
Least Common Mechanism
●
Psychological acceptability
●
Weakest Link
●
Leveraging Existing Components

6. 1st try

7. Source: istio.io

8. Source: istio.io

9. Istio’s Security Statements
●
Security by default: no changes needed to application code and
infrastructure
●
Defense in depth: integrate with existing security systems to
provide multiple layers of defense
●
Zero-trust network: build security solutions on distrusted
networks
●
Authorization and Audit Tools (AAA Tools)

10. TLS Termination
apiVersion: v1
kind: Secret
metadata:
name: mytls-credential
type: kubernetes.io/tls
data:
tls.crt: |
XYZ...
tls.key: |
ABc...
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: mygateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: SIMPLE
credentialName: mytls-credential
hosts:
- myapp.mycompany.de
Nearly full functionality of API
Gateway with Istio

11. Entire Mesh mTLS
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: istio-system #entire mesh
spec:
mtls:
mode: STRICT #PERMISSIVE
Rotating certificate every 24h
Source: istio.io

12. NetworkPolicy
●
Additional Network providers: Antrea, Canico,
Cilium, ...
●
NetworkPolicy for K8S on Layer 3 and 4
●
Istio (mainly) operates on Layer 7
●
According to OWASP: Defense in Depth

13. NetworkPolicy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: access-myapp
namespace: my-namespace
spec:
podSelector:
matchLabels:
app: myapp
ingress:
- from:
- podSelector:
matchLabels:
istio: ingressgateway
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
namespace: my-namespace
spec:
podSelector: {}
policyTypes:
- Ingress

14. 2nd try

15. AuthZ
Source: istio.io

16. AuthN
●
Can be applied to every other workload
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
name: ingress-idp
namespace: istio-system
spec:
selector:
matchLabels:
istio: ingressgateway
jwtRules:
- issuer: "my-issuer"
jwksUri: https://idp.mycompany.de/.well-known/jwks.json
●
JWT issued by
specified IDP
●
Multiple issuers
possible
●
Applied to Istio
ingress gateway

17. AuthZ
●
Request without JWT has no authentication identity but is
allowed
●
Allow-nothing rule for complete mesh
●
Applied in root namespace (istio-system)
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-nothing
namespace: istio-system
spec:
#action defaults to ALLOW if not specified
{}

18. AuthZ apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: my-app
namespace: my-namespace
spec:
selector:
matchLabels:
app: my-app
action: ALLOW
rules:
- from:
- source:
principals: ["cluster.local/ns/ns-xyz/sa/my-partner-app"]
- source:
namespaces: ["ns-abc", “ns-def”]
to:
- operation:
methods: ["GET"]
paths: ["/info*"]
- operation:
methods: ["POST"]
paths: ["/data"]
when:
- key: request.auth.claims[iss]
values: ["https://idp.my-company.de"]

19. AuthZ
●
AuthorizationPolicy
precedence
●
Rules can be very fine
grained
●
Multiple combinations
can be possible
●
be aware of complexity!
(kiss)

20. AuthZ Customized apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: external-authz
namespace: my-namespace
spec:
selector:
matchLabels:
app: my-app
action: CUSTOM
provider:
name: my-provider
rules:
- to:
- operation:
paths: ["/data",”/api”]
●
Provider must be defined in
mesh config
●
Can be applied on every workload
●
HTTP Status: 200, 403
●
Header transformations
extensionProviders:
- name: "my-provider"
envoyExtAuthzHttp:
service: "my-provider.foo.svc.cluster.local"
port: "8000"
includeHeadersInCheck: ["authorization", "cookie"]
headersToUpstreamOnAllow: ["authorization", "new-header"]
headersToDownstreamOnDeny: ["content-type", "deny-header"]

21. Audit
●
Current only Stackdriver
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
namespace: my-namespace
name: audit-my-app
spec:
selector:
matchLabels:
app: my-app
action: AUDIT
rules:
- to:
- operation:
methods: [”POST”,”PUT”,”DELETE”]
paths: ["/data/*"]

22. Final

23. Rules Summary
Functionality Rules
TLS termination (gateway) Gateway and Secret
mTLS PeerAuthentication
Network Segmentation NetworkPolicy default-deny-ingress
one per workload
Authentication RequestAuthentication
Authorization AuthorizationPolicy allow-nothing
one per workload

24. AuthZ in MicroProfile
@LoginConfig(authMethod = "MP-JWT", realmName = "MY-REALM")
@DeclareRoles("edit-role, select-role")
@ApplicationPath("/")
public class MyApplication extends Application {
}
@Path("/myendpoint")
@DenyAll
public class MyEndpoint {
@Inject
private JsonWebToken jwt;
@Resource
Principal principal;
@RolesAllowed("edit-role")
@POST
...
}
●
MicroProfile MP-JWT
Spec
●
Roles mapping on JWT
claim: groups
●
Validate against IDP

25. Summary
●
Establish security step-by-step: Starting point: only 6 rules necessary
●
Only 1 rule for mTLS in whole cluster including certificate rotation
●
JWT validation (everywhere)
●
Fine grained authZ control by infrastructure (entry-point, every service):
KISS
●
Customizable authZ control
●
Audit (only stackdriver)
●
Defense in depth (3): NetworkPolicy, AuthorizationPolicy, authZ in service
●
Zero Trust