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.
Reassessing the Bedrock of Clinical Function Models: An Examination of Large ...
The Easy Way to Secure Microservices
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
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)
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
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
{}
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