VMware Tanzu and Entrust CloudControl: Integration Guide

1. From the Home tab, select Inventory > Kubernetes Clusters .

2. On the Clusters page, select Actions > Add Kubernetes Cluster .

   If there are no clusters in your system, you can also select Add Kubernetes Cluster on the Kubernetes Clusters page.

3. On the Add Kubernetes Cluster Import tab, choose one of the following:

   • Select Import File , then select Browse and choose the kubeconfig file that you want to import.

   • Select Enter Text , then paste the contents of the kubeconfig file as plain text.

   A kubeconfig file is a configuration file written in YAML that describes the cluster that you want to add.

   To import the Management cluster, use the Management cluster config file produced earlier, management.kubeconfig.txt .

4. Select Enter Text , then paste the contents on the Management cluster config file as plain text.

5. Select Continue .

6. On the Clusters tab, select the Tanzu Management cluster you want to add and select Continue .

   You can only select one cluster. Select the Tanzu Management cluster IP address or FQDN.

7. The Select User dialog appears. Select the user who has access to the cluster.

8. Select Continue .

9. On the About tab, enter the following:

   • Friendly Name : Enter the user-facing name for the cluster.

   • Password : Enter the password for the user selected who has access to the cluster. In this example, that is the same password used by [email protected] .

     For the Vendor Type , CloudControl detects that this is a Tanzu Management cluster.

10. Select Continue .

11. On the Details tab, you can monitor the process.

12. Select Continue .

13. On the Master Nodes tab, a list of nodes will be displayed with their name, IP, and hostname information.

14. Select Continue .

15. After the cluster has been imported into CloudControl the cluster dashboard is shown.

After that the Tanzu Management cluster has been on-boarded, you can import a Tanzu Kubernetes cluster.

1. From the Home tab, select Inventory > Kubernetes Clusters .

2. On the Clusters page, select Actions > Add Kubernetes Cluster .

3. On the Add Kubernetes Cluster Import tab, select Enter Text , then paste the contents of the kubeconfig file as plain text.

   To import the Tanzu Kubernetes cluster, use the Tanzu cluster config file tanzucluster.kubeconfig.txt .

4. Select Enter Text , then paste the contents on the Tanzu Kubernetes cluster config file as plain text.

5. Select Continue .

6. On the Clusters tab, select the Tanzu Kubernetes cluster you want to add and select Continue .

   You can only select one cluster. Select the Tanzu Kubernetes cluster IP address or FQDN.

7. On the About tab, enter the following:

   • Friendly Name : Enter the user-facing name for the cluster.

   • Password : Enter the password for the user who has access to the cluster. In this example, that is the same password used by [email protected] .

     For the Vendor Type , CloudControl detects that this is a Tanzu Kubernetes cluster.

8. Select Continue .

9. On the Details tab, you can monitor the process.

10. Select Continue .

11. On the Master Nodes tab, a list of nodes will be displayed with their name, IP, and hostname information.

12. Select Continue .

13. In the Enable Access Control dialog, either:

    1. Select Enable Access Control to enable the ROOT Access Control Trust Manifest. CloudControl will take control of managing access to the cluster and you will have to create a Trust Manifest Access Control Policy to be able to create and manage objects in the cluster.

    2. Select No, not now to wait until later. This feature can be enabled after the cluster has been onboarded.

14. After the cluster has been imported into CloudControl the cluster dashboard is shown.

During the on-boarding process, root access was not enabled for the imported cluster. As a result, you can still create objects at the Tanzu level.

For example, you can create a pod. The pod.yaml file is below:

To create the pod:

The pod is created successfully. This process will fail if root access control is enabled using default HyTrust Global Access Control Policy, which denies all operations. See Enable root access control .

To delete the pod:

The pod is deleted successfully. This process will fail if root access control is enabled using default HyTrust Global Access Control Policy, which denies all operations. See Enable root access control .

When you enable root access control for the Kubernetes cluster, access control of the Tanzu Kubernetes cluster is transferred to CloudControl.

To enable root access control:

1. From the Home tab, select Inventory > Kubernetes Clusters .

2. Select Management to view the clusters.

3. Select the Tanzu Kubernetes Cluster Name that you want to enable root access control for by selecting the cluster name link.

   This action will display the details about the cluster you selected.

   If you look into the Details section of the page, you will notice that Access Control is Disabled .

4. Select the Disable link to Enable Root Access Control .

5. In the Access Control dialog, set Status to Enabled and select Apply .

After root access is enabled, you cannot work with objects directly. For example, creating a pod:

In this example, you are unable to create the pod, as CloudControl now controls permissions on the cluster. You must now give users permissions to perform actions, see Create a Trust Manifest Access Control Policy .

You can use the logs in the system to check why access has been denied for a request. From this, you can create a Trust Manifest Access Control Policy to allow the user to perform the request successfully. For more information refer to Log Analysis in the online documentation.

1. Go to the Home tab, select Security > Log Analysis .

2. Select the record that shows the Deny status to see the reason for the denial.

   Look for an entry similar to the following:

   In this example, a request to create a pod was denied.

You can now create a Trust Manifest Access Control Policy to allow the user to create the pod.

This section describes how to use an Access Control Policy to allow users to create pods in the Tanzu cluster.

In the example below, the Access Control Policy will allow the kubernetes:admin user to create pods in the cluster. Any other user in the system will be denied access.

For details of how to create an Access Control Policy, refer to Creating an Access Control Trust Manifest from the CloudControl GUI in the online documentation.

1. From the Home tab, select Security > Trust Manifests .

2. On the Manage Trust Manifests page, select Create Trust Manifest . This is the plus sign in the GUI.

3. On the Details tab of the Create Trust Manifest page, enter the Name and optional Description for the Trust Manifest.

4. For Policy Type , select Access Control .

5. In the Access Control Policy section, enter the name of the rule. That is, ACP .

6. For Role , select ASC_ContainerInfraAdmin .

   This is the role that controls all operation related to creating objects in cluster.

7. Under Subjects :

   1. For Type , select Kubernetes .

   2. For Group or User , add:

      • k8s::user:kubernetes:admin

      • k8s::user:sso:[email protected]

8. Select Validate to validate the policy.

9. Select Save to save the policy.

10. Select Publish to publish the policy.

    When you publish the policy it will ask you to assign resources to the policy. Select the Tanzu Kubernetes cluster and select Assign .

11. Select Close .

To test if the Access Control policy is working, create the pod:

The request is successful.

To test the deletion of a pod:

In this example, the resource is not found in CloudControl. This is because the CloudControl has not updated its cluster inventory yet. When you onboard the cluster, it creates an internal job that runs every 5 minutes to update the cluster inventory. This means that the only way to delete the pod in this case is to:

• Wait for the cluster inventory job to complete.

• Manually sync the inventory.

To manually sync the inventory:

1. In the Cluster Detail tab, select Actions > Sync Inventory .

2. Select Initiate Sync .

After the sync completes you should be able to delete the pod. For example:

The pod deletes successfully.

• Private Registries

  Allows you to enter a list of private registries, either onboarded or not, that you want to evaluate with the trust manifest. Only the images from registries listed in the Allowed Registries section are evaluated to see if they can be deployed. Images from all other registries will be denied.

• Signature Rule

  Allows you to deny images that do not have an associated digital signature.

• Attributes Rule

  Allows you to deny or deploy images based on their image ID or image name.

• Vulnerabilities Rule

  Allows you to deny or deploy images based on CVSS scores or specific CVEs.

A public registry rule enables images from public registries to be deployed in your environment without any evaluation.

Rules can either have a True or False value and can also include a 'stop processing' clause. Deployment rules in a policy are evaluated in the following order:

• If False, the image will not be deployed, and no further rules are evaluated.

• If True, AND there is a 'stop processing' clause, the image is allowed to be deployed and no further rules are evaluated.

• If True, the next rule in the policy is evaluated. If this is the only rule, then the image is allowed to be deployed.

• If all rules are True, then the image is allowed to be deployed.

When you create any Image Deployment Control Policy rules, you should use the image name with SHA to ensure that the intended image is evaluated no matter what tags are there. If you use an image name with tag, such as TestImage:3 , then only the image that matches that specific tag will be selected. The other images, TestImage:4 and TestImage:5 will not be evaluated.

This section will show how you can use an Image Deployment Control Policy to control which images are allowed/denied in your deployment.

For more information refer to Creating a Deployment Control Trust Manifest from the CloudControl GUI in the online documentation.

1. From the Home tab, select Security > Trust Manifests .

2. On the Manage Trust Manifests page, select Actions > Create Trust Manifest .

3. On the Details tab of the Create Trust Manifest page, enter the Name and optional Description for the trust manifest.

4. For Policy Type , select Deployment Control .

5. In the Deployment Control Rules: Private registries section:

   1. For Allowed Registries , enter the registries that you want to allow. That is:

      • Enter the registry that was onboarded: xxxxx.yyyy.zzz .

      • Enter the registries can be existing onboarded registries or registries that you plan to onboard.

      • Enter the registries that have not been onboarded are depicted with a yellow warning icon.

6. In the Deployment Control Rules: Rules section:

   1. For Signature Rule , select either Enabled or Disabled . This determines whether to deny an image when no signature is present.

7. In the Deployment Control Rules: Rules section:

   1. For Attribute Rule , select Enabled or Disabled to determine whether to evaluate using attributes, and then complete the following:

      1. Name - Enter the name of the rule. The name cannot contain any special characters.

      2. Exemption List - Deploy on Match

         Select ENABLED or DISABLED to determine whether to use this when evaluating.

         If ENABLED , use the + and - symbols to add the following criteria:

         • Image ID - Enter the image ID in SHA format to match.

         • Image Name - Enter the Name and Tag Regex to match.

         If there is a match, the image will immediately be deployed, and no other deployment policy rules will be evaluated.

         If there is no match, continue to the next enabled step.

         If there are no other steps, continue to the next rule in the deployment policy.

      3. Whitelist - Deny on No Match

         Select ENABLED or DISABLED to determine whether to use this when evaluating.

         If ENABLED , use the + and - symbols to add the following criteria:

         • Image ID - Enter the image ID in SHA format to match.

         • Image Name - Enter the Name and Tag Regex to match.

         If there is no match, the image will immediately be denied, and no other deployment policy rules will be evaluated.

         If there is a match, continue to the next enabled step.

         If there are no other steps, continue to the next rule in the deployment policy.

      4. Blacklist - Deny on Match

         Select ENABLED or DISABLED to determine whether to use this when evaluating.

         If ENABLED , use the + and - symbols to add the following criteria:

         • Image ID - Enter the image ID in SHA format to match.

         • Image Name - Enter the Name and Tag Regex to match.

         If there is a match, the image will immediately be denied, and no other deployment policy rules will be evaluated.

         If there is no match, continue to the next rule in the deployment policy.

   2. Optional. In the Public Registries section, you can add public registries to be deployed without any evaluation.

      Entrust recommends that you leave this section enabled, but do not enter any values for Allowed Registries .

8. Select one of the following:

   • Validate - Validate the draft or existing trust manifest.

   • Save - Save the trust manifest as a draft.

   • Publish - Publish the trust manifest.

In this example, an Image Deployment Control Policy is created. It will only allow images that are in the private registry that was onboarded earlier. Any other image that is not in the private registry will be blocked and will not run.

To be able to publish the policy:

• The Restrict Public Registry rule will be enabled.

• A fake registry name abc will be added to the exception list. This will force the policy to only allow images in the private registry.

After this policy is published, you can attempt to deploy an image that is not in the registry.

For example, using the pod.yaml file again:

In this example, the pod was not deployed because it uses an image from the tutum registry.

To use an image from a private registry using a different YAML file. For example, pod-internal-registry.yaml with the following content:

Create the pod:

The deployment is successful, because the Image Deployment Control Policy allows images from the private registry.

You can add the tutum external registry to the external registry exception list, so an external image can also be deployed. For example:

Create the pod using pod.yaml file again:

The deployment policy is working as designed.

You can expand the policy by further restricting what images can be deployed from the private registry.

To determine what images are in the private registry:

1. In the Home tab, Select Inventory > Image Registries and select the private registry that was onboarded.

2. Look at the images that are available in the registry.

You can change the deployment policy to only allow images with name cv-test and with the latest tag. Any other image in the private registry that does not match this requirement in the name will be blocked.

To do this, add an Attribute Rule to the deployment policy. For example:

You can now try to deploy the busybox image in the private registry. To do this, create a file called pod-internal-busybox.yaml with the following content:

When you try to deploy this, it should fail and deny the deployment. For example:

You can now deploy the cv-test image in the private registry. To do this, use the pod-internal-registry.yaml file again.

The deployment is successful.

This demonstrates how to harden the Image Deployment Control Policy.

When you onboard a private registry into CloudControl, the system checks the number of vulnerabilities in each image in the registry. Below is an example of what you see on the private registry that was onboarded.

For each image, CloudControl collects the number of vulnerabilities and their types. You can select a link in the Vulnerabilities column to view a pop-up with tabs that include the details.

The Vulnerabilities tab lists each vulnerability with their CVE, severity, and description. Select the CVE link to view details about the CVE. For example:

With this information on hand, now you can create modify the Image Deployment Control Policy to allow/deny deployments based on the number of vulnerabilities an image contain.

For example, modify the current Image Deployment Control Policy to allow any image from the private registry, but only if it has no vulnerabilities. This requires the use of two images from the private registry:

• cv-test - which has no vulnerability.

• ojw-httpd - which has some vulnerabilities.

Modify the Image Deployment Control Policy

Test the policy

% kubectl create -f pod-internal-registry.yaml

pod/internalregistry-cv-test created

apiVersion: v1
kind: Pod
metadata:
    name: internalregistry-ojw-httpd
spec:
    containers:
    - name: internalregistry-ojw-httpd
      image: xxxxx.yyyy.zzz/ojw-httpd:latest

% kubectl create -f pod-internal-cve.yaml

Error from server (Forbidden): error when creating "pod-internal-cve.yaml": admission webhook "deploymentcontrol.hytrust.com" denied the request: Permission Denied by HyTrust Security Policy.