Use an authorization policy to control service access across namespaces -

By default, services can access each other across namespaces in a Kubernetes cluster. For example, services that are deployed to a namespace in a development environment can access services in a production environment. The zero-trust security system of Service Mesh (ASM) allows you to dynamically configure authorization policies to prevent all services in one namespace from accessing services in another namespace. This helps reduce risks. This topic describes how to use an authorization policy to control service access across namespaces. The demo-frontend and demo-server namespaces are used in the example.

Prerequisites

The cluster is added to the ASM instance. For more information, see Add a cluster to an ASM instance.
The demo-frontend and demo-server namespaces are created, and sidecar proxies are injected into the two namespaces. For more information, see Manage global namespaces.

Step 1: Create test services

Create a service named sleep in the demo-frontend namespace and a service named httpbin in the demo-server namespace. The sleep service is used to send requests to access the httpbin service.

Connect to a Container Service for Kubernetes (ACK) cluster by using kubectl. For more information, see Obtain the kubeconfig file of a cluster and use kubectl to connect to the cluster.

Create a service named sleep in the demo-frontend namespace.

Create a sleep.yaml file that contains the following content:

Expand to view the sleep.yaml file

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sleep
---
apiVersion: v1
kind: Service
metadata:
  name: sleep
  labels:
    app: sleep
    service: sleep
spec:
  ports:
  - port: 80
    name: http
  selector:
    app: sleep
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sleep
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sleep
  template:
    metadata:
      labels:
        app: sleep
    spec:
      terminationGracePeriodSeconds: 0
      serviceAccountName: sleep
      containers:
      - name: sleep
        image: curlimages/curl
        command: ["/bin/sleep", "3650d"]
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: /etc/sleep/tls
          name: secret-volume
      volumes:
      - name: secret-volume
        secret:
          secretName: sleep-secret
          optional: true
---

Run the following command to create the sleep service:
```
kubectl apply -f sleep.yaml -n demo-frontend
```

Create a service named httpbin in the demo-server namespace.

Create an httpbin.yaml file that contains the following content:

Expand to view the httpbin.yaml file

apiVersion: v1
kind: ServiceAccount
metadata:
  name: httpbin
---
apiVersion: v1
kind: Service
metadata:
  name: httpbin
  labels:
    app: httpbin
    service: httpbin
spec:
  ports:
  - name: http
    port: 8000
    targetPort: 80
  selector:
    app: httpbin
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpbin
      version: v1
  template:
    metadata:
      labels:
        app: httpbin
        version: v1
    spec:
      serviceAccountName: httpbin
      containers:
      - image: docker.io/kennethreitz/httpbin
        imagePullPolicy: IfNotPresent
        name: httpbin
        ports:
        - containerPort: 80

Run the following command to create the httpbin service:
```
kubectl apply -f httpbin.yaml -n demo-server
```

Verify that a sidecar proxy is injected into both the sleep and httpbin services.
1. Log on to the ACK console. In the left-side navigation pane, click Clusters.
2. On the Clusters page, click the name of the cluster that you want to manage and choose Workloads > Pods in the left-side navigation pane.
3. In the upper part of the Pods page, select demo-frontend from the Namespace drop-down list and click the pod name of the sleep service.
  On the Container tab, a sidecar proxy named istio-proxy is displayed. This indicates that a sidecar proxy is injected into the sleep service.
4. In the upper part of the Pods page, select demo-server from the Namespace drop-down list and click the pod name of the httpbin service.
  On the Container tab, a sidecar proxy named istio-proxy is displayed. This indicates that a sidecar proxy is injected into the httpbin service.

Step 2: Create peer authentication policies

You can create peer authentication policies for namespaces so that you can authorize services in the namespaces based on Transport Layer Security (TLS).

Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management.
On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose Mesh Security Center > PeerAuthentication. On the page that appears, click Create mTLS Mode.
Select demo-frontend from the Namespace drop-down list, enter a name in the Name field, select STRICT - Strictly Enforce mTLS from the mTLS Mode (Namespace-wide) drop-down list, and then click Create.
Repeat the preceding steps to create a peer authentication policy for the demo-server namespace to enable mutual TLS (mTLS) authentication.

Step 3: Verify that an authorization policy can be used to control service access across the namespaces

You can create an authorization policy and modify the action parameter in the authorization policy to deny or allow service access from the demo-frontend namespace to the demo-server namespace. This way, you can control service access across the namespaces.

Create an authorization policy to deny access requests from the demo-frontend namespace to the demo-server namespace.

Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management.
On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose Mesh Security Center > AuthorizationPolicy. On the page that appears, click Create.

On the Create page, configure the parameters that are described in the following table and click Create.

Parameter	Description
Name	Enter the name of the authorization policy.
Policy Type	Set Policy Type to DENY.
Namespace	On the Workload Scope tab, set Namespace to demo-server.
Effective Scope	On the Workload Scope tab, set Effective Scope to Namespace Scope.
Request Matching Rules	In the Add Request Source section, turn on the Namespaces switch and set the value to `demo-frontend`.

Access the httpbin service.
1. Log on to the ACK console. In the left-side navigation pane, click Clusters.
2. On the Clusters page, click the name of the cluster that you want to manage and choose Workloads > Pods in the left-side navigation pane.
3. In the upper part of the Pods page, select demo-frontend from the Namespace drop-down list. Find the pod name of the sleep service and click Terminal > sleep in the Actions column.
4. Run the following command on the terminal of the sleep container to access the httpbin service:
```
curl -I httpbin.demo-server.svc.cluster.local:8000
```
  Expected output:
```
HTTP/1.1 403 Forbidden
content-length: 19
content-type: text/plain
date: Wed, 11 Oct 2023 08:15:25 GMT
server: envoy
x-envoy-upstream-service-time: 4
```
  The preceding output indicates that the services in the demo-frontend namespace failed to access the services in the demo-server namespace.
Change the value of the action parameter in the authorization policy to ALLOW to allow access requests from the demo-frontend namespace to the demo-server namespace.
1. Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management.
2. On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose Mesh Security Center > AuthorizationPolicy.
3. On the AuthorizationPolicy page, find the authorization policy that you want to manage and click YAML in the Actions column.
4. In the Edit dialog box, change the value of the action parameter to ALLOW, and then click OK.
Run the following command on the terminal of the sleep container to access the httpbin service:
```
curl -I httpbin.demo-server.svc.cluster.local:8000
```
Expected output:
```
HTTP/1.1 200 OK
server: envoy
date: Wed, 11 Oct 2023 08:21:40 GMT
content-type: text/html; charset=utf-8
content-length: 9593
access-control-allow-origin: *
access-control-allow-credentials: true
x-envoy-upstream-service-time: 13
```
The preceding output indicates that the services in the demo-frontend namespace successfully access the services in the demo-server namespace.
The test results indicate that an authorization policy can be used to control service access across namespaces.