Settings and Integrations

A Settings resource holds the external integrations PaletteAI uses to provision infrastructure and govern artificial intelligence and machine learning (AI/ML) workloads. The System, Tenants, and Projects each reference a Settings resource, and the controller uses the integrations defined there to communicate with Palette and the registries that supply your models.

A single Settings resource can hold up to one of each integration type. Settings resources are namespace-scoped, so the integrations they configure are always evaluated in the context of a specific System, Tenant, or Project.

Integrations

PaletteAI supports the following integration types, each filling a distinct role in the deployment lifecycle.

• Palette — Connects PaletteAI to the Spectro Cloud Palette platform. PaletteAI uses Palette as its infrastructure provider to deploy and manage the Kubernetes clusters that host your applications. A Palette integration is required for any Project that deploys Compute Pools, so every Settings resource must include one.

• Hugging Face (optional) — Provides API access to the Hugging Face Hub, allowing PaletteAI to fetch model metadata and download model artifacts. Adding a Hugging Face integration to a Settings resource unlocks Hugging Face model governance at the Project level.

• NVIDIA NGC (optional) — Provides credentials for pulling NVIDIA Inference Microservices (NIMs) from the NVIDIA NGC registry. Adding an NVIDIA NGC integration unlocks per-Project governance for the NIMs your teams can deploy.

For the Settings resource schema and field-level details, refer to the Settings Custom Resource Definition (CRD) reference.

Scope and Inheritance

Settings belong to one of three levels: the System namespace (pai-system), a Tenant namespace, or a Project namespace. The placement determines who the integrations apply to.

• System-level Settings are managed by system administrators from the System namespace (pai-system). They can share Hugging Face and NVIDIA NGC integrations with, and lock them for, selected Tenants and their Projects.

• Tenant-level Settings are referenced by the Tenant and can share Hugging Face and NVIDIA NGC integrations with selected Projects within that Tenant.

• Project-level Settings are referenced by a Project and apply only to that Project.

The scope hierarchy is System → Tenant → Project. Hugging Face and NVIDIA NGC integrations cascade down this hierarchy, resolved for each integration independently: a higher scope whose integration is locked forces its value onto the scopes it is shared with (a System lock overrides Tenant and Project; a Tenant lock overrides Project but not a locked System integration), and otherwise the most-specific scope that defines the integration wins (Project over Tenant over System). Sharing is controlled per integration by the sharedWith field. For the steps to create and manage Settings, refer to Configure Settings.

Palette integrations are not shared between scopes. Each System, Tenant, and Project must define its own Palette integration with its own credentials.

The Settings controller computes the merged result and writes it to the status.effectiveSettings field, which is the authoritative resolved configuration. The scope field in each integration within status.effectiveSettings indicates whether it came from the System, Tenant, or Project level. When integrations are merged from different scopes, each integration's secret references resolve in the namespace where the integration was defined. System-scoped integrations resolve against System secrets (pai-system); Tenant-scoped integrations resolve against Tenant secrets; Project-scoped integrations resolve against Project secrets. This keeps credentials isolated even when a Project's effective configuration is assembled from multiple scopes.

For more information on how Tenant and Project resources relate, refer to Multi-Tenancy.

Palette Integration Scope Constraints

PaletteAI enforces scope-parity rules between PaletteAI resources and Palette credentials to prevent organizational misconfigurations.

Constraint Rules

Constraint	Scope	Description
Secret uniqueness	Namespace	No duplicate secret references or contents within a namespace
Palette project uniqueness	PaletteAI Tenant (+ System)	A Palette project (hostUrl + defaultProjectID) can be used by only one Settings within a PaletteAI tenant and cannot also be claimed by a system-scoped Settings.
Project-Tenant parity	Project → Tenant	A PaletteAI Project's Palette integration must belong to the same Palette tenant as its parent PaletteAI Tenant's Palette integration
Tenant uniqueness	Across PaletteAI Tenants	No two PaletteAI tenants can use the same Palette tenant

Palette Identity Resolution

When you configure a Palette integration, PaletteAI resolves the full Palette identity:

1. From the Palette secret: Reads the hostUrl and defaultProjectID immediately.
2. From the Palette API: Calls the Palette API to resolve the Palette tenant name and UID (best-effort; retries on the next reconciliation cycle if the API is unreachable).

The resolved identity is recorded on status.paletteStatus:

• endpoint — Palette API URL
• projectUID — Palette project identifier (from secret)
• tenantName — Palette Tenant name (from API)
• tenantUID — Palette Tenant identifier (from API)

PaletteAI uses this identity to validate the constraint rules above. If either projectUID or tenantUID cannot be resolved, the Settings is marked with FailedToVerifyUniqueness until the identity is available.

Conflict Resolution

When multiple Settings violate a constraint, PaletteAI determines a winner (remains healthy) and marks losers with a PaletteIntegrationUnique condition status of False:

1. Tenant-scoped Settings are preferred over project-scoped Settings.
2. Among peers at the same scope, the oldest Settings (earliest creation timestamp) wins.

For example, if a PaletteAI Tenant and one of its child Projects both use the same Palette project, the Tenant Settings remains healthy and the Project Settings is flagged.

Project Model Settings

Hugging Face and NVIDIA NGC integrations at the Settings level unlock per-Project model governance through the Project resource's modelSettings field. Project admins use Model Settings to decide which models are available within a Project, independent of which integrations are configured at the System or Tenant level.

Model Settings cover two concepts:

• Allow and disallow lists — For each integration enabled on a Project, you can list the model repositories or NIMs that are permitted, denied, or both. A common pattern is to allow everything from a registry except a specific organization or tag.

• Profile Bundle mappings — Map model attributes to a Profile Bundle so PaletteAI automatically selects the correct Workload Profile for a given model source. For example, every Hugging Face model tagged for a particular runtime can be routed to a Profile Bundle tuned for that runtime.

Model Settings only take effect when the corresponding integration is configured in the resolved Settings.

For field-level details on modelSettings and the underlying Access Control List (ACL) syntax, refer to the Project CRD reference.