Glossary

One definition per term, as Tetrate Patch Service uses it.

Clusters and Reporting

Agent

The lightweight controller installed in each cluster that watches Deployments and DaemonSets and reports every running container image to the Patch Service. It is read-only, has no Pod access, and binds no ports.

For more details, see Clusters and the Agent.

Cluster

A Kubernetes cluster registered with the Patch Service, recognized by its own identity and labeled with a name that is unique within your organization. A cluster counts as connected only once its agent reports.

For more details, see Viewing Your Clusters.

Cluster Identity

The stable identity a cluster carries of its own, read from the cluster and fixed for its lifetime. Reports are filed under it rather than under the cluster's name, so two clusters can never share one record.

For more details, see Clusters and the Agent.

Cluster Source

Where a cluster was reached from, shown in gray under its name in the console: kubeconfig for one connected with your own credentials, or the provider, account, and region for one found in a connected cloud account.

For more details, see Viewing Your Clusters.

Snapshot

One full report from an agent: the complete set of containers running in its cluster at that moment. Each snapshot replaces the previous one, so the console shows current state, never history.

For more details, see Clusters and the Agent.

Onboarding

Connecting a cluster to the Patch Service: registering it, applying its credentials, naming it, and installing the agent, optionally together with a managed product. Every onboarding step is idempotent.

For more details, see Connecting Clusters.

Install Target

What a cluster is given when it is connected through a cloud account: the agent alone, or a product and environment, which installs the agent alongside the product.

For more details, see Installing Across Your Fleet.

Vulnerability Scanning

CVE Finding

One vulnerability on one image: a CVE reported by a scan against an image your clusters run, carrying a severity, a category, a status, and the date it was first detected.

For more details, see CVE Scanning and Findings.

Severity

The impact rating of a finding. The Patch Service reports CRITICAL and HIGH vulnerabilities that have a fix available; lower severities and unfixable CVEs are left out because upgrading is the remediation path.

For more details, see CVE Scanning and Findings.

Status

Whether a finding is open or resolved. Only a scan changes a finding's status; there is no manual dismiss.

For more details, see Investigating Findings.

Category

Who acts on a finding: actionable (an upgrade fixes it now), pending (the fix arrives in Tetrate's next release), or third party (not a Tetrate-distributed image, informational).

For more details, see CVE Scanning and Findings.

First Detected

The immutable timestamp when a finding was first reported. Re-detection never resets it, so a finding's age is the age of the problem rather than of the last scan, and it is what orders findings within a severity.

For more details, see CVE Scanning and Findings.

Scan Freshness

How recent the newest completed scan is. The console warns when it is more than 48 hours old, says so distinctly when no scan has ever completed, and never presents missing scan data as clean.

For more details, see Monitoring Vulnerabilities.

Image Summary

The per-image rollup in the By Image tab: open CVE counts, category split, the clusters running the image, and when it was last scanned.

For more details, see Monitoring Vulnerabilities.

Releases

Release Manifest

The machine-readable JSON record of one component's releases: its latest version and, for every version, the release date and exact image references with registry-verified digests.

For more details, see Release Catalog.

Release Catalog

All release manifests together, published to a public CDN with no authentication. The single source of truth behind finding categorization, upgrade markers, and upgrade pull requests.

For more details, see Release Catalog.

Image Variant

A build flavor of a released image, for example distroless or FIPS. Matching is always like for like, so an upgrade suggestion never crosses variants.

For more details, see Release Catalog.

Upgrade Target

The latest released reference of an image's own variant: what the orange Upgrade available marker names and what an actionable finding carries as its fix.

For more details, see Release Catalog.

GitOps and Upgrades

Managed Data Plane

The opt-in tier where Tetrate owns your data plane's desired state through a per-customer GitOps repository that ArgoCD continuously reconciles into your clusters.

For more details, see Managed Data Plane.

GitOps Repository

Your organization's private repository on GitHub holding the data plane's desired state. What is on main is what runs; nothing changes in a cluster except through it. Your accounts hold read access, so changes arrive as pull requests.

For more details, see Working with Your Repository.

Product

A Tetrate offering seeded as a top-level directory in your repository, deploying to one or more environments. The agent directory is reserved and is not a product.

For more details, see Managed Data Plane.

Environment

A named deployment stage of a product, such as dev or prod, living under the product's envs/ directory; default when a product runs only one. Each environment upgrades independently.

For more details, see Managed Data Plane.

Version Files

The Tetrate-managed files (values-versions.yaml) pinning the chart revision and every container image separately. Upgrades arrive as pull requests changing only these; never edit them by hand.

For more details, see Working with Your Repository.

Customer Files

The files that are yours (values-customer.yaml): resource requests, affinities, gateway placement, and similar customization. Tetrate never overwrites them.

For more details, see Working with Your Repository.

Upgrade Pull Request

The pull request an automated job opens in your repository when a tracked image falls behind the release catalog. One per layer, updated in place, and merged only once someone in your organization releases it.

For more details, see Receiving Managed Upgrades.

Pull Request Commands

The comments that drive a pull request in your repository: /approve releases it, /hold pins it shut, /merge lands it, and /close dismisses it. They exist because read-only accounts cannot give an approving review GitHub would count.

For more details, see Approving Changes.

Approval Checks

The three checks on every pull request in your repository: customer-approval (your release signal), customer-hold (whether someone asked it to wait), and tetrate-approval (green unless the change reaches beyond the files you own). All three must be green before anything merges.

For more details, see Approving Changes.

Cloud Discovery

Cloud Connection

A standing link to one cloud account, made by creating an IAM role the Patch Service assumes. No cloud credential is stored, and deleting the role revokes the connection.

For more details, see Connecting an AWS Account.

External ID

The connection-specific value your IAM role requires before it can be assumed. It is derived rather than stored, so there is no secret to leak.

For more details, see Connecting an AWS Account.

Discovered Cluster

A cluster found by scanning a connected cloud account, identified by its cloud identity and correlated against the clusters already onboarded.

For more details, see Installing Across Your Fleet.

Accounts and Access

Customer

Your organization's tenant in the Patch Service: its users, clusters, findings, and, on the managed data plane, its GitOps repository. Every user belongs to exactly one customer.

For more details, see Accessing the Patch Service.

Provisioning

Tetrate creating everything a customer needs: the account, its users, the agents' machine identity, the onboarding credentials, and, for managed customers, the GitOps repository.

For more details, see Accessing the Patch Service.

Tetrate CLI

The tetrate command-line tool for connecting and managing clusters, downloaded from the console through Download CLI. Self-contained, with no login command: it signs in through your browser when needed.

For more details, see Installing the Tetrate CLI.

Tetrate Hub

Tetrate's container registry. Onboarding delivers the image-pull credentials your clusters need to pull Tetrate images from it.

For more details, see Connecting Clusters.