Mission: Istio Security

ISTIO Security mission

Table of Contents

• Description
• User Problem
• Concepts and Architectural Patterns
  • Related concepts from Istio documentation:
• Prerequisites
• Booster Application
• Use Cases
  • Scenario #1. Mutual TLS
  • Scenario #2. Access control
• Acceptance Criteria
  • Vert.x-specific Acceptance Criteria
  • Swarm-specific Acceptance Criteria
  • Boot-specific Acceptance Criteria
  • Node.js Acceptance Criteria
• Integration Requirements
• Tags
• Notes
• Approval

ID	Short Name
108	istio-security

Group	Owner
Security	Gytis Trikleris

Description

This mission showcases Istio security concepts whereby access to services is controlled by the platform rather than independently by constituent applications.

Here we’ll outline how to apply a security policy that allows clients to obtain a greeting from a Greeting Service while forbidding direct access to the underlying implementation. Further, we’ll explore different ways to change this policy on the fly.

User Problem

In a microservice topology, not all services are intended to be invoked over the public internet. In fact, opening access in this fashion often presents a security hole. It is therefore far more prudent to restrict invocations only to known clients or dependent services.

Concepts and Architectural Patterns

• Security

• Istio

• Mutual TLS

Related concepts from Istio documentation:

• Security

• Mutual TLS

Prerequisites

1. OpenShift cluster running with Istio and authentication.

2. Automatic sidecar injection is enabled.

3. oc is available and is logged in to the cluster.

4. oc has permissions to create namespaces, service accounts and grant them permissions.

Booster Application

A dual-module application with a web page and a greeting service in one deployment and a name service in another deployment.

Name service returns a configurable name string, by default - "World".

Greeting service first gets a name from the name service and then returns a greeting message string - "Hello, ${name}!".

Web page has a mission description and a button with a result field. Buttons trigger a REST call to the greeting service and displays whatever is returned in the result field.

Example Spring Boot implementation

Use Cases

Before starting the scenarios, deploy the services with FMP or S2I.

Scenario #1. Mutual TLS

This scenario demonstrates a mutual transport level security between the services.

1. Open booster’s web page via Istio ingress route.

   1. echo http://$(oc get route istio-ingress -o jsonpath='{.spec.host}{"\n"}' -n istio-system)/

2. Click "Invoke" button. You should see "Hello, World!" message in a result box.

3. Modify greeting service’s deployment to not inject Istio sidecar. Do that by setting all sidecar.istio.io/inject annotation values to false in the greeting service’s deployment configuration.

   1. oc edit deploymentconfigs/<greeting deployment name>

4. Open booster’s web page via greeting service’s route. We cannot access it via Istio ingress any more, because this service is no longer part of the service mesh.

   1. echo http://$(oc get route <greeting route name> -o jsonpath='{.spec.host}{"\n"}' -n $(oc project -q))/

5. Greeting service invocation will fail with a reset connection, because the greeting service has to be inside a service mesh in order to access the name service.

6. Cleanup by setting sidecar.istio.io/inject values to true

   1. oc edit deploymentconfigs/<greeting deployment name>

Scenario #2. Access control

This scenario demonstrates access control when using mutual TLS.

1. Open booster’s web page via Istio ingress route.

   1. echo http://$(oc get route istio-ingress -o jsonpath='{.spec.host}{"\n"}' -n istio-system)/

2. Click "Invoke" button. You should see "Hello, World!" message in a result box.

3. Configure Istio Mixer to block greeting service from accessing name service. rules/block-greeting-service.yml configures a denier with a rule to block a request from a greeting to a name service.

   1. oc apply -f rules/block-greeting-service.yml

4. Click 'Invoke' button. You should see an HTTP 403 error, because the greeting service request to the name service has failed.

5. Now configure Istio Mixer to only allow requests to a name service from a greeting service with an sa-greeting service account. This rule works in the same way as the previous one, just has a different matcher.

   1. oc apply -f <(sed -e "s/TARGET_NAMESPACE/$(oc project -q)/g" rules/require-service-account-and-label.yml)

6. Click 'Invoke' button. You should see "Hello, World!" message. This requests chain works, because greeting service is deployed with a service account sa-greeting.

7. Cleanup

   1. oc delete -f rules/require-service-account-and-label.yml

Acceptance Criteria

1. Booster’s web page contains mission description.

2. Mutual TLS acceptance criteria.

   1. Greeting service is outside service mesh and name service is inside service mesh.

      1. "Invoke" click returns an error.

   2. Greeting and name services are inside service mesh.

      1. "Invoke" click returns "Hello, World!”.

3. Access control acceptance criteria (label and service account is required to access name service).

   1. rule/block-greeting-service.yml enabled

      1. "Invoke" click returns an error.

   2. rule/require-service-account-and-label.yml enabled

      1. "Invoke" click returns "Hello, World!".

Vert.x-specific Acceptance Criteria

Pending team input.

Swarm-specific Acceptance Criteria

Pending team input.

Boot-specific Acceptance Criteria

Pending team input.

Node.js Acceptance Criteria

Pending team input.

Integration Requirements

Tags

Notes

To be checked:

• Can we access some “TLS info” from the web page to verify if a pod is a member ?

• How we can exclude a pod from TLS and enable it after

Approval

Spring Boot	☑
Swarm	☑
DevExp	☑