KServiceName() is non-injective: distinct (project, domain, name) can map to the same KService name (delimiter ambiguity + 32-bit suffix)

[3em0]

Summary

KServiceName() derives the Knative Service name for an app from its (project, domain, name) identity, and all apps share the single flyte namespace. The current derivation is not injective — two different app identities can produce the same KService name. Combined with Deploy()'s Get → Create/Update (last-writer-wins) behavior, a second app that resolves to an already-used name will update the existing KService's spec rather than create a distinct object.

Filing this as a robustness/correctness concern. There's one thing I couldn't determine from the code (the access model) — see the question near the end; the answer decides whether this is only a same-tenant footgun or can cross ownership boundaries.

Observed in app/internal/k8s/app_client.go (commit 5df13b9).

The mapping

func KServiceName(id *flyteapp.Identifier) string {
    raw := strings.ToLower(fmt.Sprintf("%s-%s-%s", id.GetName(), id.GetProject(), id.GetDomain()))
    if len(raw) <= 63 { return raw }
    sum := sha256.Sum256([]byte(id.GetProject() + "/" + id.GetDomain() + "/" + id.GetName()))
    suffix := hex.EncodeToString(sum[:4])   // 4 bytes = 32-bit suffix
    prefix := raw
    if len(prefix) > 54 { prefix = prefix[:54] }
    return prefix + "-" + suffix
}

Observations

1. Delimiter ambiguity (raw <= 63 path). The three fields are joined by -, and project/domain may themselves contain -, so the concatenation is ambiguous. Minimal illustration — both triples satisfy every declared field constraint, yet collide:

   • {name: "svc", project: "team", domain: "prod-x"} → svc-team-prod-x
   • {name: "svc", project: "team-prod", domain: "x"} → svc-team-prod-x

2. 32-bit suffix (raw > 63 path). When raw exceeds the 63-char limit, uniqueness rests on a 4-byte (32-bit) SHA-256 suffix (sum[:4]). That's a small space to guarantee global uniqueness across all (project, domain, name) triples. The retained 54-char prefix does not add uniqueness against a specific existing name, because the leading bytes can be reproduced while only the tail (beyond position 54, e.g. in a long domain) is varied.

3. Field-validation asymmetry. In flyteidl2/app/app_definition.proto, name is constrained (max_len = 30 + DNS-1123 label pattern), but project and domain carry only min_len = 1 — no max length and no charset restriction — so they can be arbitrarily long and contain -. I also didn't find a protovalidate interceptor wired on the app handler (only an otel interceptor in app/setup.go), so even these declarative constraints may not be enforced at the RPC boundary.

4. Single shared namespace + last-writer-wins. All KServices live in namespace flyte, and Deploy() does Get(name); on hit it sets existing.Spec = ksvc.Spec, merges labels/annotations (including flyte.org/app-id), and Update()s. So a name collision means the later Create/Update overwrites the earlier app's KService spec instead of producing a separate object — an integrity concern for whoever created the name first.

Access-model question (couldn't determine from the code)

InternalAppService.Create validates only that id/spec/payload are non-nil; it doesn't check that the caller is entitled to the requested (project, domain). In the unified flyte binary (manager/cmd/main.go) the mux is wrapped only with corsMiddleware. Could a maintainer clarify the intended access model — is (project, domain) authorized against the caller's tenant somewhere upstream? That determines whether a name collision is confined to a single tenant or can affect another tenant's app.

Suggested hardening

• Make the name derivation injective/unambiguous (length-prefix or escape the fields, or hash a canonical unambiguous encoding of the triple), and widen the truncated hash well beyond 32 bits.
• Validate project/domain (max length + DNS-safe charset, mirroring name) and wire a protovalidate interceptor so the proto constraints are actually enforced.
• Consider per-tenant namespaces rather than a single shared flyte namespace.
• On Deploy, reject an update whose target KService is owned by a different app identity (compare the flyte.org/app-id annotation before Update).

Note on disclosure

Per SECURITY.md I'm glad to move this to the private security-advisory channel if you'd prefer to triage it there. I have a fuller local reproduction (a faithful copy of KServiceName() plus a Deploy() Get→Update simulation) that I can share privately.

[runllm]

The issue you describe—KServiceName() being non-injective due to delimiter ambiguity and a short (32-bit) hash suffix—means distinct (project, domain, name) triples can map to the same Knative Service name, risking accidental overwrites in the shared flyte namespace. This is a real robustness and correctness concern, as confirmed by your code analysis and the observed last-writer-wins behavior in Deploy(). The data sources do not mention KServiceName(), Knative, or the specific implementation details you reference, so I cannot confirm or refute the exact mechanics or access model from the provided documentation.

However, Flyte's design emphasizes immutability, reproducibility, and strong separation via projects and domains, which are intended to prevent cross-team interference and ensure traceability and reliability of workflow executions. The data sources do not discuss the specifics of service name derivation, namespace sharing, or access control for app deployments, so your suggested hardening steps (injective naming, stronger validation, per-tenant namespaces, and ownership checks) are not addressed or contradicted in the available documentation. Would you like a step-by-step breakdown of Flyte's project/domain isolation and how it relates to your concerns?

Sources:

• https://www.union.ai/docs/v2/union/deployment/byoc/single-sign-on-setup/microsoft-entra-id/

---

This is an AI-generated response and your feedback is appreciated! Please leave a 👍 if this is helpful and 👎 if it is not.

Mention @Herald to ask follow-up questions. See runllm.com for more!

[paullongtan]

Hi @machichima ,
I'd like to work on this issue. Thanks!

[paullongtan]

Hi @machichima ,

During the implementation of a non-injective kService name, a few design questions came to mind. Can you provide some input on this?

First, my proposal for the updated kServiceName is to use the format of k2-<lowercase-app-name>-<lowercase-base32-hash>.
The hash would be derived from a length-prefixed encoding of the App identity, hashed once with SHA-256, truncated to 128 bits, and encoded as 26 characters of unpadded lowercase Base32. With the current 30-character App name limit, the complete name is at most 60 characters.

Before implementing, could you confirm:

1. Is the unique App identity (project, domain, name) or (org, project, domain, name)?
2. Must existing KServices and public URLs continue working, or is a breaking rename acceptable? (I propose that we retain a legacy lookup strategy where existing KServices can be searched up using the current name)
3. If backward compatibility is required, should existing Apps retain legacy names while only new Apps use the k2- format?

Thanks!