Starting with UCP 3.1, Kubernetes and Swarm roles have separate views. You can view all of the roles for a particular cluster under **Access Control** > **Roles**. Select **Kubernetes** or **Swarm** to view the specific roles for each.

You can create Kubernetes roles through either the CLI using [kubectl](https://kubernetes.io/docs/reference/kubectl/overview/) or the UCP user interface (the procedure that follows).

5. Select a namespace from the **Namespace** drop-down list. Selecting a specific namespace creates a role for use in that namespace, however selecting all namespaces creates a ClusterRole where you can create rules for cluster-scoped Kubernetes resources as well as namespaced resources.

7. Select **Create**.

Kubernetes provides two types of role grants, **ClusterRoleBinding** (which applies to all namespaces) and **RoleBinding** (which applies to a specific namespace).

To create a grant for a Kubernetes role in the UCP UI:

1. Select **Access Control**.

3. Select the **Kubernetes** tab at the top of the window to view all of the grants available to Kubernetes roles.

4. Select **Create New Grant** to start the Create Role Binding wizard and create a new grant for a given user, team, or service.

5. Select the subject type, **All Users**, **Organizations**, or **Service Account**.

8. Select **Next**.

9. Select the **Cluster Role** from the drop-down list. If you select **Apply Roles Binding to all namespaces** to create a ClusterRolebinding, only **ClusterRoles** can be selected. If, though, you select a specific namespace you can choose any role from that namespace or any ClusterRole.

10. Select **Create**.

* [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)

* [Find Kubernetes Resources](https://docs.docker.com/ee/ucp/kubernetes/kube-resources/)

title: Audit logging on UCP

description: Learn how to enable audit logging of all activity in UCP.

individual users, administrators, or software components that have affected the

API, Swarm API, and Kubernetes API endpoints that are invoked (except for the

ignored list) and sent to Docker Engine through standard output (stdout). Creating audit logs is a UCP component that integrates with Swarm, Kubernetes, and UCP APIs.

Three audit logging levels are provided to give administrators more control:

- **None:** Audit logging is disabled.

- **Metadata:** Includes the following:

calls). The names of created or updated resources are not included.

- **Request:** Includes all fields from the Metadata level as well as the

Audit logs can be of help with historical troubleshooting, security analysis and auditing, generating chargeback information, and creating useful alerts.

Enable audit logging using either the UCP UI, the UCP API, or the UCP configuration file.

1. Access the UCP UI and browse to the Admin Settings page.

2. Select **Audit Logs.**

3. In the **Configure Audit Log Level** section, select the relevant logging

4. Click **Save.**

1. Download the UCP Client bundle [from the command line](https://success.docker.com/article/download-client-bundle-from-the-cli).

2. Retrieve the JSON file for the current audit log configuration.

With Docker Universal Control Plane (UCP), you can enforce applications to only use Docker images signed by UCP users you trust. Each time a user attempts to deploy an application to the cluster, UCP checks whether the application is using a trusted Docker image (and will halt the deployment if that is not the case).

By signing and verifying Docker images, you ensure that:

* The images used in your cluster are ones that you trust.

* The images have not been altered either in the image registry or on their way from the image registry to your UCP cluster.

1. A developer makes changes to a service and pushes the changes to a version control system.

2. A continuous integration (CI) system creates a build, runs tests, and pushes an image to Docker Trusted Registry (DTR) with the new changes.

3. The quality engineering team pulls the image and runs more tests. If the tests are successful, the team signs and then pushes the image.

4. The IT operations team deploys a service. If the image used for the service was signed by the QA team, UCP deploys it. Otherwise, UCP refuses to deploy the image.

To configure UCP to only allow running services that use Docker trusted images:

1. Access the UCP UI and browse to the **Admin Settings** page.

2. In the left navigation pane, click **Docker Content Trust**.

3. Select the **Run only signed images** option.

{: .with-border}

With this setting, UCP allows deploying any image as long as the image has

been signed.

To enforce the requirement that the image be signed by specific teams, click **Add Team** and select the pertinent teams from the list.

{: .with-border}

If you specify multiple teams, the image needs to be signed by a member of each

team, or by someone that is a member of all of those teams.

4. Click **Save.**

At this point, UCP starts enforcing the policy. Existing services will continue running and can be restarted if needed, however UCP only allows the deployment of new services that use a trusted image.