IstioAuthPolicies.md

Istio Auth Policy and Mesh Policy Results

Test the behavior of various implementations of mTLS for Auth Policies AND Mesh Policies so that we have the right logic implemented when we determine the config mTLS state for the Details API

Set Up

For testing these scenarios, I installed AspenMesh in a bare cluster without enabling mTls by default (use install/kubernetes/aspenmesh.yaml) but otherwise set it up normally according to the Aspen Mesh and Istio Docs.

I used the Istio setup described here

Follow the setup steps in this doc

Make sure that there are no Auth Policies or MeshPolicies yet:

kubectl get policies.authentication.istio.io --all-namespaces

(If there are any, delete them now.)

Next run this script to contact each of the apps in the namespaces you created in the setup above. ...

for from in "foo" "bar" "legacy"; do kubectl exec $(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name}) -c sleep -n ${from} -- curl http://httpbin.foo:8000/ip -s -o /dev/null -w "sleep.${from} to httpbin.foo: %{http_code}\n"; done

...You should get this response showing that legacy, which does not have a sidecar cannot talk to containers in the mesh due to the MeshPolicy being set to mTls enabled.

sleep.foo to httpbin.foo: 200     *** In Mesh Pod to Pod within 1 ns (foo)
sleep.bar to httpbin.foo: 200     *** In Mesh Pod/NS-bar to Pod/NS-foo
sleep.legacy to httpbin.foo: 200  *** OutofMesh Pod/NS-legacy to InMesh Pod/NS-foo

• Make sure to create a Destination Rule to enable mTls for all traffic per the Istio Docs.

You can apply and delete policies, then run the curl script to see results.

YOU MAY NEED TO WAIT 1-2 MINUTES FOR PODS TO SHOW THE UPDATED CONFIG.

For Mesh Policy, if the response is a 200, it means that mtls is not enabled... While 5xx means it has been enabled.

Results

The following policies were implemented, then tested using the setup above. They have been divided into 3 sections to help you determine what your policy has actually implemented.

MTLS DISABLED

The following examples of valid Auth Policies will result in services that allow unauthenticated traffic.

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: "default"
  namespace: "foo"
spec:

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: "default"
  namespace: "foo"
spec:
  peers:

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: "details-disabled"
  namespace: "foo"
spec:
  targets:
    - name: details

MTLS ENABLED

The following examples of valid Auth Policies will result in services that allow only authenticated traffic.

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: "default"
  namespace: "foo"
spec:
  peers:
  - mtls: {}

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: "default"
  namespace: "foo"
spec:
  peers:
  - mtls: 

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: "default"
  namespace: foo
spec:
  peers:
  - mtls:
      mode: STRICT

MTLS MIXED

The following examples of valid Auth Policies will result in services that allow both authenticated and unauthenticated traffic.

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: "default"
  namespace: "foo"
spec:
  peers:
  - mtls: {}
  peerIsOptional: true

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: "default"
  namespace: "foo"
spec:
  peers:
  - mtls:
      mode: STRICT

  peerIsOptional: true

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: "default"
  namespace: foo
spec:
  peers:
  - mtls:
      mode: PERMISSIVE