docs(meshery): add security self-assessment for incubation by angellk · Pull Request #2264 · cncf/toc

angellk · 2026-08-05T01:57:01Z

Summary

Security self-assessment for Meshery, authored by Meshery maintainers following the
TAG Security self-assessment template.

Required for incubation due diligence (#1386).

Original: Google Doc
Covers: actors, actions, goals, non-goals, security functions, development pipeline,
vulnerability history (5 CVEs, all SQL injection, all fixed), and compliance posture
Follows the TAG Security template structure

Checklist

DCO signed
Follows TAG Security self-assessment template

Security self-assessment authored by Meshery maintainers following the TAG Security template. Covers actors, actions, goals, non-goals, security functions, development pipeline, vulnerability history, and compliance posture. Required for incubation DD (cncf#1386). Signed-off-by: Karena Angell <karena.angell@gmail.com>

angellk · 2026-08-10T18:11:30Z

@evankanderson @mnm678 please let me know if you have any concerns! I plan to wrap up this due diligence later this week. 🙏

evankanderson · 2026-08-11T05:48:29Z

@JustinCappos @realshuting are doing most of the security-assessments reviews; I'll also do a quick pass.

JustinCappos · 2026-08-11T06:31:24Z

+- Meshery is not a secrets manager / vault. It does not encrypt credentials at rest at the application layer; the datastore must be protected via disk/file/cloud controls, and a dedicated secrets manager should hold long-lived secrets.
+- Meshery does not replace Kubernetes' own controls. It relies on the cluster's RBAC, NetworkPolicy, and Pod security mechanisms; Meshery ships no NetworkPolicies and applies no container hardening (securityContext) by default, leaving those to the operator.
+- Meshery does not constrain resource consumption of authorized callers. An authorized user can issue operations (large discoveries, benchmarks, deployments) that consume cluster or server resources.
+- The security of out-of-tree and community extensions is out of scope for the core project. Meshery is deliberately extensible via adapters, providers, and models/integrations, and community extensions are maintained in a separate meshery-extensions organization. Enabling a third-party adapter, remote provider, or integration extends a deployment's trust boundary to that extension; vetting and securing it is the responsibility of its author/operator. This assessment covers the core meshery/meshery platform and its supporting repositories, not arbitrary third-party extensions.


Is this something that users expect? It seems like one might expect at least some isolation from community plugins. How do you convey this limitation to users? How do they validate the plugins? How do you handle malicious / insecure plugins? What is the takedown process?

JustinCappos · 2026-08-11T06:31:59Z

+
+The following are explicitly out of scope for the Meshery open-source project. Several correct earlier informal descriptions of Meshery's posture.
+
+- Meshery does not provide mutual TLS or transport encryption between its own internal components by default. The server-adapter gRPC channel is plaintext today, and the server-broker (NATS) channel ships without auth or TLS by default. Securing these channels is a deployment responsibility and an active hardening roadmap item; it is not an out-of-the-box "zero-trust" guarantee.


Is this something users expect? Why don't you provide / encourage mTLS?

JustinCappos · 2026-08-11T08:05:08Z

+
+## Non-goals
+
+The following are explicitly out of scope for the Meshery open-source project. Several correct earlier informal descriptions of Meshery's posture.


Can you show how in your docs you help to guide users to understand these things?

JustinCappos · 2026-08-11T08:05:51Z

+- **Software supply-chain integrity controls.** Mandatory DCO sign-off, required peer review with branch protection, and a CI gate (lint/static analysis, CodeQL, container and dependency scanning, OpenSSF Scorecard, OSPS Baseline) that must pass before merge or release. See [Development pipeline](#development-pipeline).
+- **Centralized input sanitization for query ordering.** A shared SanitizeOrderInput routine was introduced to close the class of SQL-injection issues found in order/sort query parameters (see [Known issues over time](#known-issues-over-time)).
+
+**Security relevant** - configurable components that materially affect the security posture of a deployment. These should also be included in threat modeling.


How can you tell what components would materially affect the security posture?

JustinCappos · 2026-08-11T08:07:58Z

+
+### Incident response
+
+- **Triage & containment.** On identifying an incident, immediate containment measures are taken (e.g., disabling affected components or applying temporary mitigations).


How can you do this for out-of-tree / community extensions? Do you have the ability to disable them after the users have installed them? Do you know who installed them?

JustinCappos

Thanks for the self assessment. I have a few questions around the way in which users can understand and assess the security of different configurations, especially around community extensions.

Could you explain in more detail? Ideally, please do so directly in the document so others see those explanations later.

evankanderson

A few comments, but as this is one of my first times doing this, I'd wait for @JustinCappos or @realshuting if possible.

evankanderson · 2026-08-11T05:51:04Z

+
+Meshery is a CNCF Sandbox project, accepted on June 22, 2021 (the public "CNCF adopts Meshery" announcement followed in October 2021). It originated as a service mesh management plane and has since broadened into a general cloud native management plane that facilitates engineering teams with the collaboration, learning, planning, and operational management of their infrastructure across Kubernetes clusters and a broad range of cloud native technologies.
+
+Much of that breadth is delivered through Meshery's extension model. Beyond its in-tree adapters and core components, functionality is extended through adapters (per-technology controllers), providers (pluggable identity, persistence, and infrastructure/API back-ends), and models/integrations (the registry of cloud native constructs Meshery can design and operate). Community extensions are developed and maintained in a dedicated meshery-extensions organization, separate from the core meshery organization, so that contributors can build and share providers and integrations without requiring endorsement from the core maintainers. CNCF has described Meshery as "a highly extensible, self-service management platform" able to manage "any infrastructure via Providers, Models, Adapters, and its other extension points" ([Scaling Organizational Structure with Meshery's Expanding Ecosystem](https://www.cncf.io/blog/2026/03/04/scaling-organizational-structure-with-mesherys-expanding-ecosystem/), CNCF, 2026). For this assessment, that distinction matters: the security boundary separates the core platform (covered here) from out-of-tree extensions, whose security posture is the responsibility of their respective authors/maintainers (see [Non-goals](#non-goals)).


Is it fair to say that for a particular meshery installation, both the core and the plugins are considered "trusted"?

evankanderson · 2026-08-11T06:21:54Z

+
+The Meshery datastore is intentionally treated as a cache of authoritative cluster state rather than a system of record, which shapes several of the security trade-offs described below.
+
+## Actors


Not required, but I've found that a diagram (mermaid or .png) can be helpful for understanding the actors in the system.

evankanderson · 2026-08-11T06:23:39Z

+
+The following components ("actors") interact to deliver Meshery's functionality (see [logical architecture](https://docs.meshery.io/concepts/architecture) for diagrams). Isolation between them rests primarily on container/process boundaries and Kubernetes RBAC; see [Non-goals](#non-goals) and [Security functions and features](#security-functions-and-features) for the boundaries Meshery does and does not enforce by default.
+
+| Actor | Function | Security / isolation measures |


Is the Kubernetes cluster another actor in the system? What about the cluster administrator or other users? (There can be actors in the system beyond the software components that you ship.)

evankanderson · 2026-08-11T06:34:33Z

+
+**1. User authentication & session establishment.** When configured with a remote provider, an unauthenticated request is redirected to the provider's browser login flow. On callback, the server receives a token and sets it as an HttpOnly cookie. On each subsequent request, AuthMiddleware calls provider.GetSession(), which (a) verifies the JWT's RS256 signature against the provider's published JWKS, (b) checks expiry, (c) performs server-side introspection against the provider to detect revocation, and (d) refreshes the token when needed. With the local provider this step is a no-op: the session is always treated as a single anonymous user and no credential is checked.
+
+**2. Authorization for management functions.** Fine-grained permissions are modeled as capability "keys" grouped into keychains and mapped to roles (User, Team Admin, Workspace Admin, Org Admin, Provider Admin, etc.) in server/permissions/keys.csv. These are seeded into the datastore at startup. Multi-user role enforcement is performed in conjunction with a remote provider; the local provider is single-user and does not enforce role separation.


The multi-user permissioning component seems important. Which actor reads the role definitions (and assignments?) from this file? Is this file re-read live, or only on server restart?

evankanderson · 2026-08-11T06:35:12Z

+
+**2. Authorization for management functions.** Fine-grained permissions are modeled as capability "keys" grouped into keychains and mapped to roles (User, Team Admin, Workspace Admin, Org Admin, Provider Admin, etc.) in server/permissions/keys.csv. These are seeded into the datastore at startup. Multi-user role enforcement is performed in conjunction with a remote provider; the local provider is single-user and does not enforce role separation.
+
+**3. Connecting a Kubernetes cluster & discovery.** A user registers a cluster by supplying a kubeconfig (stored as a Credential/K8sContext). Meshery deploys the Meshery Operator, which provisions MeshSync and the Broker. MeshSync watches the resource types permitted by its watch-list and publishes ADDED/MODIFIED/DELETED events to the NATS subject meshery-server.meshsync.store; the server consumes these and persists them as KubernetesResource records. Sensitive inputs here include cluster credentials and any discovered Secrets.


Kubeconfigs can contain credentials (secrets). Is there a mechanism to ensure that these credentials are encrypted at rest?

evankanderson · 2026-08-11T08:47:08Z

+
+**3. Connecting a Kubernetes cluster & discovery.** A user registers a cluster by supplying a kubeconfig (stored as a Credential/K8sContext). Meshery deploys the Meshery Operator, which provisions MeshSync and the Broker. MeshSync watches the resource types permitted by its watch-list and publishes ADDED/MODIFIED/DELETED events to the NATS subject meshery-server.meshsync.store; the server consumes these and persists them as KubernetesResource records. Sensitive inputs here include cluster credentials and any discovered Secrets.
+
+**4. Designing and deploying infrastructure.** A user composes a Meshery Design from registry components and requests deployment. The server validates the design against model/relationship policies (Rego/OPA evaluation) and then applies the resulting manifests to the target cluster using its Kubernetes client. Because the server holds broad cluster RBAC, it can create/update/delete arbitrary resources on the user's behalf.


Is the Kubernetes client separate from the meshery adapters described above? I'm assuming "the server" is the "meshery server" in actors.

evankanderson · 2026-08-11T08:50:39Z

+**Critical** - design elements that make the product itself secure. These are recommended primary inputs to threat modeling and should be tracked as high-impact items for changes.
+
+- **Provider authentication gate.** All API access flows through AuthMiddleware > provider.GetSession(). For remote providers this performs RS256 JWT signature verification against the provider's JWKS, expiry validation, server-side introspection (to honor revocation), and token refresh. This is the central authentication control for multi-user deployments.
+- **Capability/role-based authorization model.** A fine-grained permission matrix (server/permissions/keys.csv) maps capabilities to roles and is enforced together with a remote provider, constraining which management actions a principal may perform.


Is the role assignment performed by the remote provider (e.g. by a JWT claim)? So far, it hasn't been clear how roles map to principals authenticated by the provider.

evankanderson · 2026-08-11T08:51:49Z

+
+- **Provider authentication gate.** All API access flows through AuthMiddleware > provider.GetSession(). For remote providers this performs RS256 JWT signature verification against the provider's JWKS, expiry validation, server-side introspection (to honor revocation), and token refresh. This is the central authentication control for multi-user deployments.
+- **Capability/role-based authorization model.** A fine-grained permission matrix (server/permissions/keys.csv) maps capabilities to roles and is enforced together with a remote provider, constraining which management actions a principal may perform.
+- **Software supply-chain integrity controls.** Mandatory DCO sign-off, required peer review with branch protection, and a CI gate (lint/static analysis, CodeQL, container and dependency scanning, OpenSSF Scorecard, OSPS Baseline) that must pass before merge or release. See [Development pipeline](#development-pipeline).


These are software supply chain checks, not product design elements, correct? (i.e. the product itself isn't enforcing DCO on end-user components)

If so, this is more relevant under "secure development practices".

angellk requested a review from a team as a code owner August 5, 2026 01:57

angellk mentioned this pull request Aug 5, 2026

[Incubation] Meshery Incubation Application #1386

Open

44 tasks

evankanderson added this to TAG Security and Compliance Aug 5, 2026

evankanderson moved this to Todo in TAG Security and Compliance Aug 5, 2026

evankanderson added the needs-triage Indicates an issue or PR that has not been triaged yet (has a 'triage/foo' label applied) label Aug 5, 2026

github-project-automation Bot added this to TAG Operational Resilience, CNCF TOC Board, TAG Workloads Foundation, TAG Developer Experience and TAG Infrastructure Aug 5, 2026

github-project-automation Bot moved this to New in CNCF TOC Board Aug 5, 2026

mnm678 added the tag/security-and-compliance TAG Security and Compliance label Aug 5, 2026

JustinCappos reviewed Aug 11, 2026

View reviewed changes

JustinCappos requested changes Aug 11, 2026

View reviewed changes

evankanderson reviewed Aug 11, 2026

View reviewed changes


		The following are explicitly out of scope for the Meshery open-source project. Several correct earlier informal descriptions of Meshery's posture.

		- Meshery does not provide mutual TLS or transport encryption between its own internal components by default. The server-adapter gRPC channel is plaintext today, and the server-broker (NATS) channel ships without auth or TLS by default. Securing these channels is a deployment responsibility and an active hardening roadmap item; it is not an out-of-the-box "zero-trust" guarantee.


		## Non-goals

		The following are explicitly out of scope for the Meshery open-source project. Several correct earlier informal descriptions of Meshery's posture.


		### Incident response

		- Triage & containment. On identifying an incident, immediate containment measures are taken (e.g., disabling affected components or applying temporary mitigations).


		Meshery is a CNCF Sandbox project, accepted on June 22, 2021 (the public "CNCF adopts Meshery" announcement followed in October 2021). It originated as a service mesh management plane and has since broadened into a general cloud native management plane that facilitates engineering teams with the collaboration, learning, planning, and operational management of their infrastructure across Kubernetes clusters and a broad range of cloud native technologies.

		Much of that breadth is delivered through Meshery's extension model. Beyond its in-tree adapters and core components, functionality is extended through adapters (per-technology controllers), providers (pluggable identity, persistence, and infrastructure/API back-ends), and models/integrations (the registry of cloud native constructs Meshery can design and operate). Community extensions are developed and maintained in a dedicated meshery-extensions organization, separate from the core meshery organization, so that contributors can build and share providers and integrations without requiring endorsement from the core maintainers. CNCF has described Meshery as "a highly extensible, self-service management platform" able to manage "any infrastructure via Providers, Models, Adapters, and its other extension points" ([Scaling Organizational Structure with Meshery's Expanding Ecosystem](https://www.cncf.io/blog/2026/03/04/scaling-organizational-structure-with-mesherys-expanding-ecosystem/), CNCF, 2026). For this assessment, that distinction matters: the security boundary separates the core platform (covered here) from out-of-tree extensions, whose security posture is the responsibility of their respective authors/maintainers (see [Non-goals](#non-goals)).


		The Meshery datastore is intentionally treated as a cache of authoritative cluster state rather than a system of record, which shapes several of the security trade-offs described below.

		## Actors


		The following components ("actors") interact to deliver Meshery's functionality (see [logical architecture](https://docs.meshery.io/concepts/architecture) for diagrams). Isolation between them rests primarily on container/process boundaries and Kubernetes RBAC; see [Non-goals](#non-goals) and [Security functions and features](#security-functions-and-features) for the boundaries Meshery does and does not enforce by default.

		\| Actor \| Function \| Security / isolation measures \|


		1. User authentication & session establishment. When configured with a remote provider, an unauthenticated request is redirected to the provider's browser login flow. On callback, the server receives a token and sets it as an HttpOnly cookie. On each subsequent request, AuthMiddleware calls provider.GetSession(), which (a) verifies the JWT's RS256 signature against the provider's published JWKS, (b) checks expiry, (c) performs server-side introspection against the provider to detect revocation, and (d) refreshes the token when needed. With the local provider this step is a no-op: the session is always treated as a single anonymous user and no credential is checked.

		2. Authorization for management functions. Fine-grained permissions are modeled as capability "keys" grouped into keychains and mapped to roles (User, Team Admin, Workspace Admin, Org Admin, Provider Admin, etc.) in server/permissions/keys.csv. These are seeded into the datastore at startup. Multi-user role enforcement is performed in conjunction with a remote provider; the local provider is single-user and does not enforce role separation.


		2. Authorization for management functions. Fine-grained permissions are modeled as capability "keys" grouped into keychains and mapped to roles (User, Team Admin, Workspace Admin, Org Admin, Provider Admin, etc.) in server/permissions/keys.csv. These are seeded into the datastore at startup. Multi-user role enforcement is performed in conjunction with a remote provider; the local provider is single-user and does not enforce role separation.

		3. Connecting a Kubernetes cluster & discovery. A user registers a cluster by supplying a kubeconfig (stored as a Credential/K8sContext). Meshery deploys the Meshery Operator, which provisions MeshSync and the Broker. MeshSync watches the resource types permitted by its watch-list and publishes ADDED/MODIFIED/DELETED events to the NATS subject meshery-server.meshsync.store; the server consumes these and persists them as KubernetesResource records. Sensitive inputs here include cluster credentials and any discovered Secrets.


		3. Connecting a Kubernetes cluster & discovery. A user registers a cluster by supplying a kubeconfig (stored as a Credential/K8sContext). Meshery deploys the Meshery Operator, which provisions MeshSync and the Broker. MeshSync watches the resource types permitted by its watch-list and publishes ADDED/MODIFIED/DELETED events to the NATS subject meshery-server.meshsync.store; the server consumes these and persists them as KubernetesResource records. Sensitive inputs here include cluster credentials and any discovered Secrets.

		4. Designing and deploying infrastructure. A user composes a Meshery Design from registry components and requests deployment. The server validates the design against model/relationship policies (Rego/OPA evaluation) and then applies the resulting manifests to the target cluster using its Kubernetes client. Because the server holds broad cluster RBAC, it can create/update/delete arbitrary resources on the user's behalf.

Uh oh!

Conversation

angellk commented Aug 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Checklist

Uh oh!

angellk commented Aug 10, 2026

Uh oh!

evankanderson commented Aug 11, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JustinCappos left a comment

Choose a reason for hiding this comment

Uh oh!

evankanderson left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

angellk commented Aug 5, 2026 •

edited

Loading