Careful!
You are browsing documentation for the next version of Kuma. Use this version at your own risk.
MeshTrafficPermission
MeshIdentity has to be enabled to make MeshTrafficPermission
work.
Overview
MeshTrafficPermission
policy defines which clients are allowed or denied access to services inside a mesh based on their identities.
By default, if no policy is present, all requests are denied.
It enables:
- denying all requests by default, or blocking specific clients (by SPIFFE ID) so that no service owner can override them
- allowing groups of clients, such as everything in the
observability
namespace, to access all services by default, while still letting individual services opt out - giving service owners control to allow specific clients, and the ability to block abusive ones even if they were previously allowed
Here is a common example:
apiVersion: kuma.io/v1alpha1
kind: MeshTrafficPermission
metadata:
name: my-app-permissions
namespace: kuma-system
labels:
kuma.io/mesh: my-mesh
spec:
targetRef:
kind: Dataplane
labels:
app: my-app
rules:
- default:
deny:
- spiffeID:
type: Prefix
value: spiffe://my-mesh.us-east-2.mesh.local/ns/legacy-ns
- spiffeID:
type: Exact
value: spiffe://my-mesh.us-east-2.mesh.local/ns/test/sa/client
allow:
- spiffeID:
type: Prefix
value: spiffe://my-mesh.us-east-2.mesh.local
With this policy in place, workloads labeled app: my-app
will reject connections from identities under the legacy-ns
namespace
as well as the specific test/client
identity, while continuing to accept connections from all other identities within the my-mesh.us-east-2.mesh.local
trust domain.
Configuration
MeshTrafficPermission
policy provides a way to specify 3 lists:
deny
list – list of matches for clients that must always be denied.allow
list – list of matchers for clients that are explicitly allowed.allowWithShadowDeny
list – list of matchers that are allowed, but also logged as if they were denied. Useful for testing a policy to ensure no legitimate clients are denied.
Evaluation rules are:
- If a request matches at least one
deny
matcher –DENY
. - Else, if it matches at least one
allow
orallowWithShadowDeny
matcher –ALLOW
. - If no matchers apply –
DENY
(default).
Examples
Denying requests from a group of clients mesh-wide
During the incident, if one of the namespaces is compromised, Mesh Operator can apply the following policy:
apiVersion: kuma.io/v1alpha1
kind: MeshTrafficPermission
metadata:
name: deny-malicious-ns
namespace: kuma-system
labels:
kuma.io/mesh: my-mesh
spec:
rules:
- default:
deny:
- spiffeID:
type: Prefix
value: spiffe://my-mesh.us-east-2.mesh.local/ns/malicious
Such policy when applied globally prevents any service in the mesh my-mesh
to receive requests from any client in malicious
namespace.
There is no way for Service Owner to opt-out from this rule.
Allowing requests from a group of clients mesh-wide
By default, when there are no MeshTrafficPermission
policies, all requests are denied.
Mesh Operator can apply the following policy mesh-wide:
apiVersion: kuma.io/v1alpha1
kind: MeshTrafficPermission
metadata:
name: allow-observability-ns
namespace: kuma-system
labels:
kuma.io/mesh: my-mesh
spec:
rules:
- default:
allow:
- spiffeID:
type: Prefix
value: spiffe://my-mesh.us-east-2.mesh.local/ns/observability
This policy allows any client in observability
namespace to consume any service in my-mesh
.
Service Owner can opt-out and deny requests from observability
if they need to:
apiVersion: kuma.io/v1alpha1
kind: MeshTrafficPermission
metadata:
name: deny-observability-ns
namespace: backend-ns
labels:
kuma.io/mesh: my-mesh
spec:
targetRef:
kind: Dataplane
labels:
app: backend
sectionName: backend-admin-api
rules:
- default:
deny:
- spiffeID:
type: Prefix
value: spiffe://my-mesh.us-east-2.mesh.local/ns/observability
The following policy overrides the rules specified in allow-observability-ns
and denies requests from clients in observability
namespace on backend-admin-api
port of backend
app.