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

 

Install Keycloak Operator

Log on to katacoda

 

execute the following commands from these sources

Read the operator SDK user guide here

Checkout this example controller

 

git clone https://github.com/keycloak/keycloak-operator.git
cd keycloak-operator
kubectl apply -f deploy/crds/
kubectl create namespace keycloak
kubectl apply -f deploy/role.yaml -n keycloak
kubectl apply -f deploy/role_binding.yaml -n keycloak
kubectl apply -f deploy/service_account.yaml -n keycloak
kubectl apply -f deploy/operator.yaml -n keycloak
kubectl apply -f deploy/examples/keycloak/keycloak.yaml -n keycloak
kubectl apply -f deploy/examples/realm/realm_with_users.yaml -n keycloak
watch kubectl get all -n keycloak

 

Wait till everything is started up

kubectl logs -f keycloak-0 -n keycloak 

kubectl exec -ti keycloak-0 -n keycloak /bin/bash

cd /opt/jboss/keycloak/standalone/configuration 

Read more about Keycloak Operator

 

Add Keycloak Metrics SPI endpoints for Prometheus

Service Provider that adds a metrics endpoint to Keycloak. The endpoint returns metrics data ready to be scraped by Prometheus.

Two distinct providers are defined:

  • MetricsEventListener to record the internal Keycloak events
  • MetricsEndpoint to expose the data through a custom endpoint

Get it at github

About Docker pull secrets

Understanding the Oauth 2.0 Authorization Code Grant Type

The Authorization Code Grant Type is probably the most common of the OAuth 2.0 grant types that you’ll encounter. It is used by both web apps and native apps to get an access token after a user authorizes an app. In OAuth 2.0, the term “grant type” refers to the way an application gets an access token. OAuth 2.0 defines several grant types, including the authorization code flow. OAuth 2.0 extensions can also define new grant types.

  1. Get the User' permission
  2. Redirect back to the Application

 

Spring Cloud Security

Spring Cloud Security offers a set of primitives for building secure applications and services with minimum fuss. A declarative model which can be heavily configured externally (or centrally) lends itself to the implementation of large systems of co-operating, remote components, usually with a central indentity management service. It is also extremely easy to use in a service platform like Cloud Foundry. Building on Spring Boot and Spring Security OAuth2 we can quickly create systems that implement common patterns like single sign on, token relay and token exchange.

  1. Read the latest reference documentation on Spring boot security Oauth2
  2. For the most common providers support read this

Springboot Oauth2 Token Relays

A Token Relay is where an OAuth2 consumer acts as a Client and forwards the incoming token to outgoing resource requests. The consumer can be a pure Client (like an SSO application) or a Resource Server.

Client Token Relays

If your app is a user facing OAuth2 client (i.e. has declared @EnableOAuth2Sso or @EnableOAuth2Client) then it has an OAuth2ClientContext in request scope from Spring Boot. You can create your own OAuth2RestTemplate from this context and an autowired OAuth2ProtectedResourceDetails, and then the context will always forward the access token downstream, also refreshing the access token automatically if it expires. (These are features of Spring Security and Spring Boot.

resource Server Token Relays

If your app has @EnableResourceServer you might want to relay the incoming token downstream to other services. If you use a RestTemplate to contact the downstream services then this is just a matter of how to create the template with the right context.

If your service uses UserInfoTokenServices to authenticate incoming tokens (i.e. it is using the security.oauth2.user-info-uri configuration), then you can simply create an OAuth2RestTemplate using an autowired OAuth2ClientContext (it will be populated by the authentication process before it hits the backend code). Equivalently (with Spring Boot 1.4), you could inject a UserInfoRestTemplateFactory and grab its OAuth2RestTemplate in your configuration. For example:

 

@Beanpublic OAuth2RestTemplate restTemplate(UserInfoRestTemplateFactory factory) {

 

    return factory.getUserInfoRestTemplate();

 

}

 

Here’s a basic example showing the use of an autowired rest template created elsewhere ("foo.com" is a Resource Server accepting the same tokens as the surrounding app):

 

@Autowiredprivate OAuth2RestOperations restTemplate; @RequestMapping("/relay") public String relay() {

    ResponseEntity<String> response = restTemplate.getForEntity("https://foo.com/bar", String.class);

    return"Success! (" + response.getBody() + ")";

}

 

 

Oauth SpringBoot properties

Now to configure on ADFS see here

Note that you also need to specify a scope property to make authentication api happy

Finally I could figured out where they are. In the google api console, after create your app, go to edit your app credentials and click in download json. All it is needed is there. In my case is like this.

What is difference between these two...

security.oauth2.client.authenticationScheme=query
security.oauth2.client.clientAuthenticationScheme=form 

see AuthorizationCodeResourceDetails

Example:

# OAuth2 configuration
security.oauth2.client.clientId=<CLIENT_ID_GENERATED_IN_PREVIOUS_STEP>
security.oauth2.client.clientSecret=<CLIENT_SECRET_GENERATED_IN_PREVIOUS_STEP>
security.oauth2.client.preEstablishedRedirectUri=http://localhost:9090/callback
security.oauth2.client.accessTokenUri=https://www.googleapis.com/oauth2/v3/token
security.oauth2.client.userAuthorizationUri=https://accounts.google.com/o/oauth2/auth
security.oauth2.client.tokenName=oauth_token
security.oauth2.client.authenticationScheme=query
security.oauth2.client.clientAuthenticationScheme=form
security.oauth2.client.scope=profile
security.oauth2.resource.user-info-uri=https://www.googleapis.com/userinfo/v2/me
security.oauth2.client.useCurrentUri=false

Best post on ADFS in chinese though

This is how you setup your client and REST API authentication schemes on ADFS for authorization code flows...

From this excellent post which I unfortunately can not translate and read )-; an excellent implementation of a Springboot 

ResourceServerTokenServices

And another great ADFS POC github link
security:
  oauth2:
    client:
      clientId: [client id setup with ADFS]
      userAuthorizationUri: https://[adfs domain]/adfs/oauth2/authorize?resource=[MyRelyingPartyTrust]
      accessTokenUri: https://[adfs domain]/adfs/oauth2/token
      tokenName: code
      authenticationScheme: query
      clientAuthenticationScheme: form
      grant-type: authorization_code
    resource:
      userInfoUri: https://[adfs domain]/adfs/oauth2/token

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.

S4U2Self

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.

Read

 

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.

Read

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