MCPRegistry (toolhive.stacklok.dev/v1beta1)

CreationTimestamp is a timestamp representing the server time when this object was created. It is not guaranteed to be set in happens-before order across separate operations. Clients may not set this value. It is represented in RFC3339 form and is in UTC.

Populated by the system. Read-only. Null for lists. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

DeletionTimestamp is RFC 3339 date and time at which this resource will be deleted. This field is set by the server when a graceful deletion is requested by the user, and is not directly settable by a client. The resource is expected to be deleted (no longer visible from resource lists, and not reachable by name) after the time in this field, once the finalizers list is empty. As long as the finalizers list contains items, deletion is blocked. Once the deletionTimestamp is set, this value may not be unset or be set further into the future, although it may be shortened or the resource may be deleted prior to this time. For example, a user may request that a pod is deleted in 30 seconds. The Kubelet will react by sending a graceful termination signal to the containers in the pod. After that 30 seconds, the Kubelet will send a hard termination signal (SIGKILL) to the container and after cleanup, remove the pod from the API. In the presence of network partitions, this object may still exist after this timestamp, until an administrator or automated process can determine the resource is fully terminated. If not set, graceful deletion of the object has not been requested.

Populated by the system when a graceful deletion is requested. Read-only. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

Must be empty before the object is deleted from the registry. Each entry is an identifier for the responsible component that will remove the entry from the list. If the deletionTimestamp of the object is non-nil, entries in this list can only be removed. Finalizers may be processed and removed in any order. Order is NOT enforced because it introduces significant risk of stuck finalizers. finalizers is a shared field, any actor with permission can reorder it. If the finalizer list is processed in order, then this can lead to a situation in which the component responsible for the first finalizer in the list is waiting for a signal (field value, external system, or other) produced by a component responsible for a finalizer later in the list, resulting in a deadlock. Without enforced ordering finalizers are free to order amongst themselves and are not vulnerable to ordering changes in the list.

GenerateName is an optional prefix, used by the server, to generate a unique name ONLY IF the Name field has not been provided. If this field is used, the name returned to the client will be different than the name passed. This value will also be combined with a unique suffix. The provided value has the same validation rules as the Name field, and may be truncated by the length of the suffix required to make the value unique on the server.

If this field is specified and the generated name exists, the server will return a 409.

Applied only if Name is not specified. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#idempotency

Namespace defines the space within which each name must be unique. An empty namespace is equivalent to the "default" namespace, but "default" is the canonical representation. Not all objects are required to be scoped to a namespace - the value of this field for those objects will be empty.

Must be a DNS_LABEL. Cannot be updated. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces

An opaque value that represents the internal version of this object that can be used by clients to determine when objects have changed. May be used for optimistic concurrency, change detection, and the watch operation on a resource or set of resources. Clients must treat these values as opaque and passed unmodified back to the server. They may only be valid for a particular resource or set of resources.

Populated by the system. Read-only. Value must be treated as opaque by clients and . More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency

ConfigYAML is the complete registry server config.yaml content.
The operator creates a ConfigMap from this string and mounts it
at /config/config.yaml in the registry-api container.
The operator does NOT parse, validate, or transform this content —
configuration validation is the registry server's responsibility.

Security note: this content is stored in a ConfigMap, not a Secret.
Do not inline credentials (passwords, tokens, client secrets) in this
field. Instead, reference credentials via file paths and mount the
actual secrets using the Volumes and VolumeMounts fields. For database
passwords, use PGPassSecretRef.

ImagePullSecrets allows specifying image pull secrets for the registry API workload.
These are applied to both the registry-api Deployment's PodSpec.ImagePullSecrets
and to the operator-managed ServiceAccount the registry API runs as, so private
images are pullable through either path.

Use this field for new manifests.

Important: this is the ONLY way to attach image-pull credentials to the
operator-managed ServiceAccount. The legacy
spec.podTemplateSpec.spec.imagePullSecrets path populates the Deployment's pod
spec ONLY — it does NOT touch the ServiceAccount. On managed Kubernetes
platforms that rely on ServiceAccount-level credential injection (for example
GKE Workload Identity, OpenShift's per-SA dockercfg secrets, EKS IRSA), using
only the legacy PodTemplateSpec path can fail to pull private images even when
the secret exists in the namespace. Always set spec.imagePullSecrets when
SA-level credentials matter.

Precedence with PodTemplateSpec:
- This field is applied first as the controller-generated default.
- Values set under spec.podTemplateSpec.spec.imagePullSecrets are user overrides
and win on overlap. If the user supplies imagePullSecrets via PodTemplateSpec,
those replace the default list on the Deployment (the list is treated atomically).
- The ServiceAccount is always populated from this field — PodTemplateSpec does not
affect the ServiceAccount.

An omitted field and an explicitly empty list are equivalent: both leave the
ServiceAccount's existing ImagePullSecrets unchanged. This preserves
platform-managed pull secrets (for example OpenShift's per-SA dockercfg
entries) when overlays or patches emit an empty list. Truly clearing the
ServiceAccount's pull secrets requires recreating the resource.

PGPassSecretRef references a Secret containing a pre-created pgpass file.

Why this is a dedicated field instead of a regular volume/volumeMount:
PostgreSQL's libpq rejects pgpass files that aren't mode 0600. Kubernetes
secret volumes mount files as root-owned, and the registry-api container
runs as non-root (UID 65532). A root-owned 0600 file is unreadable by
UID 65532, and using fsGroup changes permissions to 0640 which libpq also
rejects. The only solution is an init container that copies the file to an
emptyDir as the app user and runs chmod 0600. This cannot be expressed
through volumes/volumeMounts alone -- it requires an init container, two
extra volumes (secret + emptyDir), a subPath mount, and an environment
variable, all wired together correctly.

When specified, the operator generates all of that plumbing invisibly.
The user creates the Secret with pgpass-formatted content; the operator
handles only the Kubernetes permission mechanics.

Example Secret:

apiVersion: v1
kind: Secret
metadata:
  name: my-pgpass
stringData:
  .pgpass: |
    postgres:5432:registry:db_app:mypassword
    postgres:5432:registry:db_migrator:otherpassword

Then reference it:

pgpassSecretRef:
  name: my-pgpass
  key: .pgpass

PodTemplateSpec defines the pod template to use for the registry API server.
This allows for customizing the pod configuration beyond what is provided by the other fields.
Note that to modify the specific container the registry API server runs in, you must specify
the registry-api container name in the PodTemplateSpec.
This field accepts a PodTemplateSpec object as JSON/YAML.

VolumeMounts defines additional volume mounts for the registry-api container.
Each entry is a standard Kubernetes VolumeMount object (JSON/YAML).
The operator appends them to the container's volume mounts alongside the config mount.

Mount paths must match the file paths referenced in configYAML.
For example, if configYAML references passwordFile: /secrets/git-creds/token,
a corresponding volume mount must exist with mountPath: /secrets/git-creds.

Volumes defines additional volumes to add to the registry API pod.
Each entry is a standard Kubernetes Volume object (JSON/YAML).
The operator appends them to the pod spec alongside its own config volume.

Use these to mount:
- Secrets (git auth tokens, OAuth client secrets, CA certs)
- ConfigMaps (registry data files)
- PersistentVolumeClaims (registry data on persistent storage)
- Any other volume type the registry server needs