Tenant isolation

(Show larger)

Provider scope and tenant scope

Every group, service and policy belongs to a scope: the provider, or one tenant. A tenant user works in the scope of the tenant and has no choice to make: the page Firewall shows only the objects of that tenant and the provider objects the tenant is allowed to see. A provider user sees the provider scope first and can look at the objects of one tenant by choosing it under Scope, next to Provider.

The scope also limits where a rule applies. A tenant policy applies only to the network adapters of that tenant, whatever its groups name, and an empty list of target groups means every adapter of the tenant. A tenant rule cannot refer to a group, service or virtual machine of another tenant: such an object does not exist for the tenant, and the console reports it as unknown.

What a tenant can do

With the firewall privileges of a tenant role, a tenant can:

• create, change and delete policies in the categories Environment and Application, and order their rules;
• create groups and services, with its own virtual machines, adapters and networks as members, any address or prefix, and tag criteria that count only its own virtual machines;
• use the shared groups of the provider as source or destination, and nest them in its own groups;
• open a port or apply a template on its own virtual machines, and choose a profile that the provider marked as selectable;
• read the effective rules, hit counters, log records and monitor reports of its own machines, and simulate a packet.

What a tenant cannot do

The provider keeps the following, and the console either hides it from tenants or reports a refusal:

• The categories Emergency and Infrastructure. A tenant sees these bands as read-only with Provider policies: read only. A tenant policy in these categories fails with error.firewall.category_scope. The block of outbound mail is one of these provider rules, so a tenant cannot open port 25; see Outbound mail on port 25.
• The members of a shared provider group. A tenant sees its name and description with Members hidden.
• Sharing a group with other tenants, and attaching tags of a category that the provider manages. This keeps a tenant from moving its virtual machines into or out of a provider group by tagging them.
• Naming groups of other scopes in Applied to.
• The mode of an adapter and its confirmation. The message Changing the mode needs the provider privilege. appears in place of the button.
• The tabs Rollout, Realization, Bypass and Settings, which exist in the provider scope only.
• Going over the quotas of the tenant for groups, policies, rules and group members. The change fails with error.firewall.quota.

Provider roles can grant a tenant role only the firewall privileges that fit a tenant. A role that holds Kyvernon.Firewall.ManageProvider or Kyvernon.Firewall.Bypass cannot be assigned inside a tenant.

Isolation on private networks

On a private host-bridge network that adapters of several tenants share, the platform keeps the tenants apart by itself. Adapters of one tenant can reach each other, and traffic from the adapters of other tenants on the same network is dropped. The platform does this with the built-in policy sys:tenant-isolation in the category Infrastructure, which no one can change. Virtual machines without a tenant count as one tenant of the provider.

Three limits apply. Adapters with a public address get no such rule, because a neighbour is treated like any other source on the internet and the default profile and the policies decide. Traffic from the gateway of the network and from outside the network is not matched by the isolation, and falls to the policies and the profile as usual. On OVN-backed networks the isolation is not applied automatically; see Firewall on OVN networks.

Related tasks

• Rules and policies creates the policies of a scope.
• Groups and services creates groups, shared groups and tag criteria.
• Default profiles marks profiles as selectable for tenants.
• Firewall concepts explains categories, profiles and modes.