Relationships as Policy

What Is a Relationship in Meshery? 🔗

Meshery’s registry organises infrastructure knowledge into three tiers: models, components, and relationships. A relationship is a typed, directional link between two component kinds. Relationships are not decorative - they carry semantic weight that the Meshery policy engine reads during design evaluation.

Each relationship definition specifies:

• Kind - the semantic category (e.g., Network, Hierarchical, Binding)
• Selectors - the source and target component types the relationship applies to
• Deny/Allow semantics - whether the combination is permitted, required, or forbidden
• Subtypes - optional refinements such as encapsulates, mounts, or permit

Because relationships live in the registry alongside models and components, they are versioned, importable, and composable across teams.

Relationships as Executable Policy 🔗

Traditional policy documents describe intent but do not participate in tooling. Meshery relationships are different: they are machine-readable constraints that the validation engine evaluates against every design, whether that design was drawn in Kanvas, imported from a YAML file, or generated by a coding agent.

Consider a relationship that asserts every Service of type LoadBalancer must be bound to a NetworkPolicy component. When a design lacks that binding, Meshery surfaces a violation during validation - before the design is applied to any cluster. The relationship is the policy; the registry is the policy store.

This model has three practical advantages over separate policy documents:

Required vs. Allowed vs. Denied Configurations 🔗

Meshery relationships fall into three enforcement postures:

Required - the validation engine fails any design that is missing the specified binding. Example: every Deployment must have a HorizontalPodAutoscaler in production workload designs.

Allowed - the combination is explicitly permitted but not mandatory. The engine does not flag its absence, but it may flag a relationship that falls outside the allowed set.

Denied - the combination is forbidden. A design that contains it fails validation immediately. Example: a Pod component must never be connected directly to an external Ingress without an intervening Service.

How Relationships Are Evaluated 🔗

When you run validation - either through mesheryctl design import -f <file> -s "Kubernetes Manifest" or through Kanvas’s live validation panel - Meshery performs a two-phase check:

1. Schema validation - component fields are checked against their model-defined JSON Schema.
2. Relationship evaluation - the policy engine walks the design graph, finds every component pair, and looks up applicable relationships in the registry. Each match is tested against the relationship’s allow/deny/require rule.

Any relationship violation is returned as a structured finding with a severity level, the offending component IDs, and the relationship rule that failed. The design is not blocked from being saved locally, but it cannot be promoted through a policy gate until violations are resolved (see the lesson on validating designs against policy).

Authoring Relationships 🔗

Relationships are defined in YAML and contributed to the Meshery registry. A minimal deny relationship looks like this:

apiVersion: core.meshery.io/v1alpha2
kind: RelationshipDefinition
metadata:
  name: pod-direct-ingress-deny
spec:
  kind: Network
  subType: permit
  selectors:
    - deny:
        from:
          - kind: Ingress
            model: kubernetes
        to:
          - kind: Pod
            model: kubernetes

Once registered, this constraint applies automatically to any design containing those component types. Teams can publish their own relationship sets to the Catalog, making shared governance rules available organisation-wide.

Connecting Relationships to Agent-Generated Designs 🔗

When a coding agent generates infrastructure YAML and imports it into Meshery, the same relationship evaluation runs. The agent does not bypass policy. If the generated design violates a required relationship, the validation result is returned to the agent’s tool call response, giving it the information needed to revise the design before a human reviews it. Relationships are therefore the primary mechanism for giving an LLM-driven workflow guardrails without requiring human inspection of every generated component.