Demo Authorization

In this lesson, we demonstrate how to apply authorization policies at both the namespace and workload levels in an Istio service mesh. These policies are essential for securing your applications by explicitly allowing or denying traffic.

Step 1: Deny All Traffic in the Default Namespace

First, verify that your application is running. Then, apply an authorization policy to the default namespace. This policy, which contains no selectors and an empty spec, denies all traffic to all workloads within the namespace.

kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-nothing
  namespace: default
spec:
  {}
EOF

The output should confirm that the policy was created:

authorizationpolicy.security.istio.io/allow-nothing created

It may take a few moments for the new policy to propagate. When you access your application using a browser, you should see an "RBAC: access denied" message because Istio lacks any rules that allow traffic:

RBAC: access denied

To further test the effect of this policy, generate continuous traffic with this command:

while sleep 0.01; do curl -s "http://${INGRESS_HOST}:${INGRESS_PORT}/productpage" &> /dev/null; done

Check your product page application both in the browser and on the Kiali dashboard. You will observe that no traffic passes through and error messages related to RBAC access denial appear in the pod logs.

Step 2: Enable Traffic for the Product Page

To allow HTTP GET requests to the product page, create a policy that selects workloads with the label app: productpage in the default namespace:

kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "productpage-viewer"
  namespace: default
spec:
  selector:
    matchLabels:
      app: productpage
  action: ALLOW
  rules:
  - to:
    - operation:
        methods: ["GET"]
EOF

After applying this policy, refresh your browser. The product page should now load correctly, while other services remain inaccessible. The Kiali dashboard will show a green connection from the ingress to the product page, confirming that allowed traffic flows as expected.

Step 3: Sequentially Enable Additional Components

Next, add further authorization policies to enable full application functionality.

3.1 Create the Details Viewer Policy

This policy applies to workloads with the label app: details and permits HTTP GET requests from the product page service account (bookinfo-productpage):

kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "details-viewer"
  namespace: default
spec:
  selector:
    matchLabels:
      app: details
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/bookinfo-productpage"]
    to:
    - operation:
        methods: ["GET"]
EOF

Once active, the details component becomes accessible, as reflected by changes in the Kiali graph.

3.2 Enable the Reviews Service

Create a policy for the reviews service. This policy selects workloads labeled with app: reviews and allows GET requests from the product page service account:

kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "reviews-viewer"
  namespace: default
spec:
  selector:
    matchLabels:
      app: reviews
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/bookinfo-productpage"]
    to:
    - operation:
        methods: ["GET"]
EOF

After applying this policy, the reviews component should become accessible. However, if ratings are still generating errors (with red indications in the Kiali graph), further action is needed.

3.3 Create the Ratings Viewer Policy

Address the issues with the ratings service by creating a policy that selects workloads with the label app: ratings and permits GET requests from the reviews service account (bookinfo-reviews):

kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "ratings-viewer"
  namespace: default
spec:
  selector:
    matchLabels:
      app: ratings
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/bookinfo-reviews"]
    to:
    - operation:
        methods: ["GET"]
EOF

Once enabled, the entire application should operate as expected. The full product page will be displayed in the browser and the Kiali graph will indicate a green status, confirming allowed traffic flows.

Step 4: Review the Istio Configuration

Take a moment to review the overall Istio configuration. In the configuration section, you will see the global "allow nothing" policy applied across the mesh along with the specific viewer policies for each component.

Conclusion

By sequentially applying targeted authorization policies, you can effectively secure your Istio service mesh while selectively enabling access to critical components of your application. For more details, consult the Istio Documentation.

For further reading on securing microservices, see:

• Kubernetes Security Best Practices
• Istio Security Concepts