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, aDestinationRule in Istio is used to configure how clients talk to a service. Istio provides 2 levels of security.

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.

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.

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.

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