Ihre Browserversion ist veraltet. Wir empfehlen, Ihren Browser auf die neueste Version zu aktualisieren.

Securing services

Istio is configured with Kubernetes Custom Resource Definition (CRD) objects. The two main objects for configuring Istio's security policies are the Policy and DestinationRule object. Policy objects are used to configure the security settings, a DestinationRule in Istio is used to configure how clients talk to a service. Istio provides 2 levels of security. 

  1. Transport authentication, also known as service-to-service authentication: mTLS (mutual) between services, Istio/Citadel taking care of key and certificate management and handles getting the certificates and keys onto the application instances. Using these certificates, Istio-enabled clusters have automatic mutual TLS. With Istio, communication between services in the mesh is secure and encrypted by default.
  2. Origin authentication, also known as end-user authentication: When we use mTLS as described above, we can not only encrypt the connection, but more importantly know exactly who is calling whom. But what happens when service A is making a request to service B on behalf of user X? Typical way for services to communicate end-user or origin identity (the user logged in) is passing identity tokens like JSON Web Tokens. These tokens are given out to represent an authenticated user and the claims that user has. Each application language/framework historically had to rely on libraries to handle verifying and unpacking the JWT tokens. For example, for the popular Keycloak Identity and SSO project, there are language plugins for each popular language to handle some of this responsibility.

Note: For origin authentication (JWT), the application is responsible for acquiring and attaching the JWT credential to the request, see.

Read Istio security concepts

Origin Authentication with Keycloak

I configured Keycloak on Active Directory by defining a keycloak user federation. End-user web client authenticating (Keycloak confidential client) over SPNEGO/Kerberos (1, 2, 3, 4 and 5) tickets and downstream REST API calls (Authorization) done over JWT tokens (6), so called Keycloak baerer-only clients.

Policy objects

To configure Istio to both use mTLS and verify the JWT token in a request (and fail the request if it doesn't exist, is invalid, or is expired), we can configure a Policy object. If a client productpage tries to connect to the reviews service, their request wouldn't make it to the service unless the JWT authentication succeeds. Another good thing about Istio's implementation here is that the request is also protected my mTLS.

DestinationRule objects

These DestinationRule objects will require clients use mTLS when making calls to services in the default namespace. We are also configuring the TLS mode to be ISTIO_MUTUAL which means we'll expect Istio to manage the certificates and keys as well as mount them into the services (using Kubernetes secrets in Kubernetes) so that the service proxy can use them to establish TLS.

Helm installing Keycloak server

This page is about installing, setting up and integrating Keycloak with MS Active Directory over LDAP.

  • git clone https://github.com/agilesolutions/charts-istio
  • cd charts-istio/charts
  • helm install keycloak/

Keycloak SpringBoot integration

Keycloak is an open source Identity and Access Management solution aimed at modern applications and services. It makes it easy to secure applications and services with little to no code.

Configure Keycloak

This example helped me a lot setting up Keycloak.

  • Create a Keycloak realm called istio.
  • Select that istio realm and Read this page how to configure a user federation to integrate your company AD over LDAP
  • Create a public client called productpage under realm istio
  • Create 2 baerer-only clients called reviews and details under realm istio
  • Keycloak is configured with default admin user admin and password admin

Testing JWT token on details service

Some examples how you can get the Autorization token from Keycloak by this Read

  • kubectl run -i --rm --restart=Never tokenizer --image=tutum/curl --command -- curl -X POST 'http://keycloak:8080/auth/realms/istio/protocol/openid-connect/token' -H "Content-Type: application/x-www-form-urlencoded" -d 'username={demo-user}&password={demo-user}&grant_type=password&client_id=cars-web' | jq .access_token
  • The above command will output Authorization token from Keycloak, store the value in an environment variable called $token
  • kubectl port-forward $(kubectl get pod -n default -l app=details -o jsonpath='{.items[0].metadata.name}') -n default 8080
  • curl -vvv -H "Authorization: Bearer $token" http://details:8080/list

Add Istio RBAC

Istio’s authorization feature - also known as Role-based Access Control (RBAC) - provides namespace-level, service-level, and method-level access control for services. To expressing role based access to your services you specify a ServiceRole and ServiceRoleBinding. ServiceRole defines a group of permissions to access services. ServiceRoleBinding grants a ServiceRole to particular subjects, such as a user, a group, or a service. Read more

Understanding Kerberos Delegation in Windows Active Directory

Delegation is managed by the S4U2proxy extension, a front-end (user facing) server can request a kerberos ticket on behalf of a user to access a subsequent back-end server, providing seamless access to data users are allowed to view or edit on that back-end.

There are 2 types of delegation, Ticket Forwarding (from kerberos to kerberos) and Protocol Transition (switching from another authentication mechanism like SAML to kerberos), explained later on.

Constrained delegation means restricting access to back-end resources that the frontend-end app is allowed to delegate to, this is done by listing back-end servers SPN's on the security principal (AD computer or service object) that runs the front-end app, explained later.

Ticket Forwarding (S4U2proxy)...


1. user authenticates to front-end app over kerberos providing a valid TGS service ticket, user's Ticket-Granting Ticket (TGT) is placed into the service ticket, allowing front-end app to authenticate on behalf of that user.

Protocol Transition (S4U2self)...

1. user authenticates against another security mechanism like like SAML.
2. ....

Enabling constrained delegation, how to.

  1. enable S4U2Self
  2. enable Protocol Transition
  3. Constraining to dedicated SPN's only












Please note that you will need to be Domain Admin or have at least the “SeEnableDelegationPrivilege” enabled in order to grant delegation.


This extension enables any server to ask for a TGS on itself for an arbitrary identity. This is done with a TGS_REQ operation where the pre-authentication data contains the desired client identity for the KDC to generate the right ticket. In a traditional TGS_REQ operation, the client identity should be the requestor, so the computer account used by the host itself.

An important note to understand what’s to come, when the TGS service on the domain controller handles the TGS_REQ, it will look at the requestor’s “userAccountControl” attribute and look for the “TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION” bit. The returned ticket will be forwardable only if this bit is set.



The relevancy of Resource-based constrained delegation.

Starting from Windows 2012/Windows 8 it is possible to configure another type of delegation: “Resource Based Constrained Delegation”. In this scenario it is the target resource (downastream REST API resource server) which decides  which computer can act on behalf another identity.  A specific new attribute was added by MS: “msDS-AllowedToActOnBehalfOfOtherIdentity” where you put the computer(s) names and the ACL’s that the destination (REST API resource server) computer will trust.


Instead of using an allow list of SPNs on the front-end app AD object, you allow the resource owner to control delegation.
When a backend service receives a request from our frontend server to grant access on behalf of another user, the AD Key Distribution Center (KDC) checks the security descriptor in the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of the security principal running the backend service, and if it matches the descriptor under which the frontend service runs, access is granted.

A note on: does this new more complicated scenario of RBCD add value or can this be considered overhead. I guess this is only profitable when you have a decentralized administration of frontend (user facing) services and backend services. In the bank all AD administration done centrally by the same team, I feel giving these people more flexibility with through powershell is only adding more complexity to the process. I don't think it is improving things from a security point of view, so what is the win?

Is it worth all the effort - YAGNI

Only advantage I see is that RBCD supports cross-realm access (spanning multiple security realm), read In general the SFU extensions are old and supported by Java since Java 8 but with windows 2012R2 Microsoft added support to cross-realm access. Previously the three roles (final user, frontend server and backend server) should be in the same realm/domain but a new concept, called resource-based constrained delegation, was incorporated to expanse SFU for multi-realm. But...The JDK never supported the new feature as stated in this JDK bug.

XXX custom library support for JBoss JEE and Springboot

The best post I found so far on this topic

Code example 1

Code example 2

On of the best examples so far

The protocol overview for S4USelf and Proxy

MS-SFU kerberos extensions and cross-realm support Important read!!!!!!


Hosted by WEBLAND.CH