Access Control

In the previous guide, we federated multiple meshes and established a shared root CA for a shared identity domain. Now that we have a logical VirtualMesh, we need a way to establish access policies across the multiple meshes, without treating each of them individually. Service Mesh Hub helps by establishing a single, unified API that understands the logical VirtualMesh construct.

Before you begin

To illustrate these concepts, we will assume that:

Be sure to review the assumptions and satisfy the pre-requisites from the Guides top-level document.

Enforcing Access Control

Ensure that your kubeconfig has the correct context set as its currentContext:

MGMT_CONTEXT=your_management_plane_context
REMOTE_CONTEXT=your_remote_context

kubectl config use-context $MGMT_CONTEXT

In another shell, start a port-forward to the bookinfo demo:

kubectl --context $MGMT_CONTEXT -n bookinfo port-forward deployment/productpage-v1 9080:9080

In a browser, visit http://localhost:9080 (potentially selecting “normal user” if this is your first time using the app) and verify that both the book details and the reviews are loading correctly. Depending on which review service is accessed you will see reviews with no stars or black stars. You can refresh the page to see the review source change.

Let's use the Service Mesh Hub AccessPolicy resource to enforce access control across the logical VirtualMesh. The default behavior is to deny-all.

In the previous guide, we created a VirtualMesh resource, but we had access control disabled. Let's take a look at the same VirtualService, with access control enabled:


apiVersion: networking.smh.solo.io/v1alpha2
kind: VirtualMesh
metadata:
  name: virtual-mesh
  namespace: service-mesh-hub
spec:
  mtlsConfig:
    autoRestartPods: true
    shared:
      rootCertificateAuthority:
        generated: null
  federation: {}
  globalAccessPolicy: ENABLED
  meshes:
  - name: istiod-istio-system-management-cluster
    namespace: service-mesh-hub
  - name: istiod-istio-system-remote-cluster
    namespace: service-mesh-hub

kubectl apply --context $MGMT_CONTEXT -f - << EOF
apiVersion: networking.smh.solo.io/v1alpha2
kind: VirtualMesh
metadata:
  name: virtual-mesh
  namespace: service-mesh-hub
spec:
  mtlsConfig:
    autoRestartPods: true
    shared:
      rootCertificateAuthority:
        generated: null
  federation: {}
  globalAccessPolicy: ENABLED
  meshes:
  - name: istiod-istio-system-management-cluster
    namespace: service-mesh-hub
  - name: istiod-istio-system-remote-cluster
    namespace: service-mesh-hub
EOF

If you saved this VirtualMesh CR to a file named demo-virtual-mesh.yaml, you can apply it like this:

kubectl --context $MGMT_CONTEXT apply -f demo-virtual-mesh.yaml

virtualmesh.networking.smh.solo.io/virtual-mesh configured

It may take a few moments for the access policy / authorizations propagate to the workloads.

With the globalAccessPolicy setting ENABLED and with no other AccessControlPolicies, we should see a deny-all access posture. Try going back to http://localhost:9080 and refresh the bookinfo sample and you should see the details and reviews services blocked.

For Istio, global access control is enforced using an AuthorizationPolicy with an empty spec, placed in Istio's root namespace (usually istio-system). More details can be found in the Istio AuthorizationPolicy documentation.

Note that Service Mesh Hub will also create additional AuthorizationPolicies in order to allow all traffic through ingress gateways so that federated traffic can continue working as expected.

Using AccessPolicy

To allow traffic to continue as before, we apply the following two updates our configuration. Respectively the additions do the following:

  1. Allow the productpage service to talk to anything in the bookinfo namespace
  2. Allow the reviews service to talk ony to the ratings service

In this configuration, we select sources (in this case the productpage service account) and allow traffic the any service in the bookinfo namespace. Be sure to update the clusterName value as needed.


apiVersion: networking.smh.solo.io/v1alpha2
kind: AccessPolicy
metadata:
  namespace: service-mesh-hub
  name: productpage
spec:
  sourceSelector:
  - kubeServiceAccountRefs:
      serviceAccounts:
        - name: bookinfo-productpage
          namespace: bookinfo
          clusterName: management-cluster
  destinationSelector:
  - kubeServiceMatcher:
      namespaces:
      - bookinfo
EOF

kubectl apply --context $MGMT_CONTEXT -f - << EOF
apiVersion: networking.smh.solo.io/v1alpha2
kind: AccessPolicy
metadata:
  namespace: service-mesh-hub
  name: productpage
spec:
  sourceSelector:
  - kubeServiceAccountRefs:
      serviceAccounts:
        - name: bookinfo-productpage
          namespace: bookinfo
          clusterName: management-cluster
  destinationSelector:
  - kubeServiceMatcher:
      namespaces:
      - bookinfo
EOF

If you saved this VirtualMesh CR to a file named demo-product-policy.yaml, you can apply it like this:

kubectl --context $MGMT_CONTEXT apply -f demo-product-policy.yaml

accesspolicy.networking.smh.solo.io/productpage created

In this next configuration, we enable traffic from reviews to ratings:


apiVersion: networking.smh.solo.io/v1alpha2
kind: AccessPolicy
metadata:
  namespace: service-mesh-hub
  name: reviews
spec:
  sourceSelector:
  - kubeServiceAccountRefs:
      serviceAccounts:
        - name: bookinfo-reviews
          namespace: bookinfo
          clusterName: management-cluster
  destinationSelector:
  - kubeServiceMatcher:
      namespaces:
      - bookinfo
      labels:
        service: ratings

kubectl apply --context $MGMT_CONTEXT -f - <<EOF
apiVersion: networking.smh.solo.io/v1alpha2
kind: AccessPolicy
metadata:
  namespace: service-mesh-hub
  name: reviews
spec:
  sourceSelector:
  - kubeServiceAccountRefs:
      serviceAccounts:
        - name: bookinfo-reviews
          namespace: bookinfo
          clusterName: management-cluster
  destinationSelector:
  - kubeServiceMatcher:
      namespaces:
      - bookinfo
      labels:
        service: ratings    
EOF

If you have this YAML saved to a file called reviews-access.yaml, you can apply it to take effect:

kubectl --context $MGMT_CONTEXT apply -f reviews-access.yaml

accesspolicy.networking.smh.solo.io/reviews created

Traffic should be allowed again.

See it in action

Check out “Part Three” of the “Dive into Service Mesh Hub” video series (note that the video content reflects Service Mesh Hub v0.6.1):

Next steps

In this section, we enabled access policies for services running in the mesh. In the next section, let's see how to control traffic routing.