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/

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


Hosted by WEBLAND.CH