Eine produktiv betriebene Anwendung kommt in der Regel nicht ohne Authorization-Checks aus. Entsprechend dem OWASP-Prinzip “Defense in Depth” sollten die AuthZ-Prüfungen nicht nur im Anwendungscode erfolgen. Eine zusätzliche Ebene für die Berechtigungsprüfung, am besten in der Cloud-Infrastruktur, gilt als Best Practice. Mit einem Service-Mesh-Tool können anwendungsspezifische deklarative Authz-Prüfungen im Sidecar durchgeführt werden. Die Möglichkeiten, die Istio hier bietet, werden in dieser Session genauer betrachtet. Aber auch TLS/mTLS und Authentication, als notwendige Voraussetzungen für AuthZ, werden ausführlich vorgestellt.

1. Service Specific AuthZ In The
Cloud Infrastructure
Michael Hofmann
Hofmann IT-Consulting
info@hofmann-itconsulting.de
https://hofmann-itconsulting.de

2. AuthZ in Java (e.g. 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 JWT Spec
●
Role mapping on special JWT
claim: “groups“
●
JWT Validation against IDP
(JWKS in config of app-
server)

3. Programmatic vs. Declarative
●
Security Policy in
Deployment/Config
●
Limited to HTTP Headers (e.g.
Token, Path, …)
●
Not Applicable on HTTP Payload
●
Easier to Change and Test
●
Evaluated by Infrastructure
●
Security Checks in Code
●
Entry-Point in Code is declarative:
@DeclareRoles, @RolesAllowed
●
Hard to Change and Test
– Code change
– Maybe scattered
●
Works on parameters and result
values (e.g. from database)
●
Always necessary when declarative
is not enough

4. 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

5. Istio
Source: istio.io

6. JWT
●
HTTP Header
“Authorization: Bearer ey...“
●
Bearer → TLS must be set
●
Claims (Standard and
Individual)
●
Issued by IDP: iss-claim
(e.g. Keycloak, ...)
{
"typ": "JWT",
"alg": "RS256",
"kid": "xy-1234567890"
}
{
"iss":
"https://idp.mycompany.de",
"aud": "my-audience",
"exp": 1649516447,
"iat": 1649520047,
"sub": "user01",
"upn":
"user01@idp.mycompany.de",
"groups": ["admin", "power-
user", ...],
"myclaim01": "myvalue01"
}

7. Gateway with 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

8. 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

9. AuthN

10. AuthN
●
Can be applied to every other workload (selector)
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

11. 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
{}

12. AuthorizationPolicy
●
(Workload) Selector
●
Action
– ALLOW
– DENY
– AUDIT
– CUSTOM
●
Rules
Rules
●
From
– RequestPrincipal vs Principal
– Namespaces
– IP Blocks, Remote IP Blocks (X-
Forwarded-For)
●
To
– Host, Ports
– Methods (HTTP-Methods), Paths
●
When (Condition)
– Key and Values

13. AuthorizationPolicy Conditions
●
request.headers
●
source.namespace and source.principal
●
request.auth.*
●
source.ip and remote.ip
●
destination.ip and destination.port
●
connection.sni

14. 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"]
AuthZ

15. Authz Service Specific

16. Explicit Deny
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: my-app-deny
namespace: my-namespace
spec:
selector:
matchLabels:
app: my-app
action: DENY
rules:
- from:
- source:
principals: ["cluster.local/ns/ns-xyz/sa/my-partner-app"]
to:
- operation:
methods: ["POST"]
paths: ["/admin"]

17. AuthZ Precedence
●
Rules can be very
fine grained
●
Multiple
combinations can be
possible
●
be aware of
complexity! (kiss)

18. JWT Claims per Path
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: my-app-deny
namespace: my-namespace
spec:
selector:
matchLabels:
app: my-app
action: ALLOW
rules:
- to:
- operation:
methods: ["POST"]
paths: ["/admin"]
when:
- key: request.auth.claims[groups]
values: ["admin"]

19. JWT Claim Based Routing
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: my-app
namespace: my-namespace
spec:
hosts:
- my-app.my-namespace.svc.cluster.local
gateways:
- secure-gateway
http:
- match:
- uri:
prefix: /admin
headers:
"@request.auth.claims.groups":
exact: admin
route:
- destination:
port:
number: 8000
host: my-app
●
AuthorizationPolicy and
VirtualService together
●
Combined with
dedicated ingress
gateway
●
Supports only Istio
Ingress Gateway

20. Dry Run
●
AuthorizationPolicy with annotation:
istio.io/dry-run: „true“
●
Test effect of policy before activating it (AuthPolicies can
have severe consequences)
●
Envoy sends a shadow request
●
Verify result
– in Prometheus as metric result or in Zipkin as trace output
– Envoy access log
●
shadow denied, matched policy ns[foo]-policy[deny-path-headers]-rule[0]

21. Authz
Customized

22. 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"]

23. Summary
●
Only 1 rule for mTLS in whole cluster including certificate rotation
●
Only declarative part of AuthZ in infrastructure
●
JWT validation (in every sidecar)
– Fine grained authZ control by infrastructure: KISS
– ingress gateway
– every service
●
Dry Run and JWT-Claim based routing
●
Customizable authZ control
●
Defense in depth