O slideshow foi denunciado.

Service Specific AuthZ In The Cloud Infrastructure

0

Compartilhar

1 de 23
1 de 23

Service Specific AuthZ In The Cloud Infrastructure

0

Compartilhar

Baixar para ler offline

Descrição

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.

Transcrição

  1. 1. Service Specific AuthZ In The Cloud Infrastructure Michael Hofmann Hofmann IT-Consulting info@hofmann-itconsulting.de https://hofmann-itconsulting.de
  2. 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. 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. 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. 5. Istio Source: istio.io
  6. 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. 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. 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. 9. AuthN
  10. 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. 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. 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. 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. 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. 15. Authz Service Specific
  16. 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. 17. AuthZ Precedence ● Rules can be very fine grained ● Multiple combinations can be possible ● be aware of complexity! (kiss)
  18. 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. 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. 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. 21. Authz Customized
  22. 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. 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

Descrição

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.

Transcrição

  1. 1. Service Specific AuthZ In The Cloud Infrastructure Michael Hofmann Hofmann IT-Consulting info@hofmann-itconsulting.de https://hofmann-itconsulting.de
  2. 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. 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. 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. 5. Istio Source: istio.io
  6. 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. 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. 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. 9. AuthN
  10. 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. 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. 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. 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. 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. 15. Authz Service Specific
  16. 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. 17. AuthZ Precedence ● Rules can be very fine grained ● Multiple combinations can be possible ● be aware of complexity! (kiss)
  18. 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. 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. 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. 21. Authz Customized
  22. 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. 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

Mais Conteúdo rRelacionado

Livros relacionados

Gratuito durante 30 dias do Scribd

Ver tudo

Audiolivros relacionados

Gratuito durante 30 dias do Scribd

Ver tudo

×