In VMware Tanzu Mission Control you can create policies of various types to manage the operation and security posture of your Kubernetes clusters and other organizational objects.

Policies allow you to provide a set of rules that govern your organization and all the objects it contains. The policy types available in Tanzu Mission Control include the following:
  • access policy

    Access policies allow you to use predefined roles to specify which identities (individuals and groups) have what level of access to a given resource. For more information, see Access Control.

  • image registry policy

    Image registry policies allow you to specify the source registries from which an image can be pulled.

  • network policy

    Network policies allow you to use preconfigured templates to define how pods communicate with each other and other network endpoints.

  • quota policy

    Quota policies allow you to constrain the resources used in your clusters, as aggregate quantities across specified namespaces, using preconfigured and custom templates. For more information, see Managing Resource Consumption in Your Clusters in Using VMware Tanzu Mission Control.

  • security policy

    Security policies allow you to manage the security context in which deployed pods operate in your clusters by imposing constraints on your clusters that define what pods can do and which resources they have access to. For more information, see Pod Security Management.

  • custom policy

    Custom policies allow you to implement additional business rules, using templates that you define, to enforce policies that are not already addressed using the other built-in policy types. For more information, see Creating Customized Policies in Using VMware Tanzu Mission Control.

Note: Some policy types are available only in the advanced version of Tanzu Mission Control. For more information, see the VMware Tanzu Mission Control Feature Comparison Chart.

Policy Inheritance

In the Tanzu Mission Control resource hierarchy, there are three levels at which you can specify policies.
  • organization
  • object groups (cluster groups and workspaces)
  • Kubernetes objects (clusters and namespaces)

In addition to the direct policy defined for a given object, each object also has inherited policies that are defined in the parent objects. For example, a cluster has a direct policy and also has inherited policies from the cluster group and organization to which it is attached.

Labels and Selectors

A label is a key/value pair attached to a Kubernetes object (such as a namespace, node, or pod) that allows you to specify identifying attributes for that object. A selector provides the means to identify the objects that have a given label.

Some types of policies allow you to specify a label selector, which identifies the objects that you want to include or exclude from the policy.

When you specify a label selector to include (or exclude) in a policy, the objects of the given type within the scope of the policy that have the specified label are included (or excluded) in the set that are impacted by the policy. If no label selectors are specified, the policy applies to all such objects within the scope of the policy.

For example, say you create a quota policy with the following details:
  • created at the cluster group level on the mycompany-project1 cluster group
  • namespace label selector to include: project1-phase:phase02
  • namespace label selector to exclude: basic:compliance

When this quota policy is saved, it impacts all clusters in the mycompany-project1 cluster group, constrains the namespaces with the project1-phase:phase02 label, and does not impact the namespaces with the basic:compliance label.

When adding label selectors, make sure you click the Add label selector button after entering the key and values. This action applies the label selector to the policy and opens a new entry row on the form. Each row (in both include and exclude) represents a rule that must match to identify the objects for which the policy is effective. These selector rules are applied as follows:
  • A rule with a key and one value is a match if a label with the specified key exists on the object and it equals the specified value.
  • A rule with a key and no value is a match if a label with the specified key exists on the object, regardless of the value.
  • A rule with a key and multiple, comma-separated values is a match if a label with the specified key exists on the object and it equals at least one of the specified values.
  • When multiple label selector rules are specified, all of the rules must be satisfied to identify the object.

For more information about label selectors, see Labels and Selectors in the Kubernetes documentation.