HMAC (Hash-based Message Authentication Code), standardised in RFC 2104 (1997) and FIPS 198-1, is a construction that produces a Message Authentication Code (MAC) by combining a cryptographic hash function with a shared secret key. A plain hash function provides integrity — any modification to a message changes its digest — but anyone can recompute the digest of a modified message, so a hash alone cannot prove that a message came from a specific party who holds a secret. HMAC adds authenticity: only a party who knows the key K can produce a valid HMAC(K, message), and only a party who knows K can verify it. The construction is HMAC(K, m) = H((K ⊕ opad) ∥ H((K ⊕ ipad) ∥ m)) — two rounds of hashing with the key XOR’d against inner and outer padding constants — a design chosen to be provably secure against length-extension attacks that affect naive H(K ∥ m) constructions with Merkle-Damgård hash functions like SHA-256. HMAC is proven secure as long as the underlying hash function is a pseudorandom function, a weaker requirement than collision resistance, meaning HMAC-SHA-256 remains secure even in scenarios where SHA-256 collision resistance might be weakened.
A cryptographic hash function maps an input of arbitrary length (a file, a certificate, a password, a block of network data) to a fixed-length digest (also called a hash or fingerprint) with three security properties that distinguish it from non-cryptographic checksums. Preimage resistance: given a digest h, it is computationally infeasible to find any input m such that H(m) = h. Second preimage resistance: given an input m1, it is computationally infeasible to find a different input m2 such that H(m1) = H(m2). Collision resistance: it is computationally infeasible to find any pair (m1, m2) with m1 ≠ m2 such that H(m1) = H(m2). Collision resistance is the strongest property and implies second preimage resistance but not preimage resistance. These properties together make a hash function a one-way, tamper-evident fingerprint: two inputs that produce the same digest cannot be found by an adversary, and knowing the digest reveals nothing about the input beyond its length.
Guardrails are controls wrapped around LLM inference to reduce harmful, non-compliant, or off-policy behavior without replacing the base model. Their objective is AI safety and governance in production: block or rewrite prompts that attempt prompt injection or jailbreaks, filter toxic or leaked PII in outputs, enforce topic allowlists, validate structured tool calls, and log decisions for audit. Guardrails sit on the request path (before tokens reach the model or after the model proposes a draft response), combining rule engines, classifiers, regex, and sometimes smaller models. They complement—not replace—application auth, network policy, and human review; enterprises treat them as mandatory for customer-facing and internal copilots.
firewalld is the firewall management daemon on RHEL, CentOS Stream, Fedora, SUSE, and their derivatives, providing a higher-level policy model and a runtime-safe management API on top of nftables (RHEL 8+ / Fedora 32+) or iptables (older systems). Its defining feature is runtime versus permanent configuration: firewall rule changes can be applied immediately to the running system without restarting the service or dropping existing connections (--runtime, the default), and separately persisted to disk so they survive reboots (--permanent). This two-phase model solves the operational problem that raw nftables or iptables rule changes traditionally required either accepting a momentary policy gap during reload or building custom transaction logic. The daemon exposes its API over D-Bus, allowing NetworkManager, libvirt, Podman, and other system components to request firewall policy changes programmatically — when a VM is started in libvirt or a container port is published in Podman, the respective tool calls firewalld over D-Bus to open the required port rather than directly manipulating nftables rules.
FIDO2 is the current generation of authentication standards produced jointly by the FIDO Alliance and the W3C, combining two specifications: WebAuthn (Web Authentication API, W3C Level 3, 2025) and CTAP2 (Client to Authenticator Protocol 2, FIDO Alliance). Its defining security property is origin binding: every FIDO2 credential is generated and used with a cryptographic binding to the specific Relying Party ID (RP ID — typically the registering domain’s origin) encoded into every authentication assertion. An authenticator will refuse to produce an assertion for evil.com using a credential registered with bank.com, even if the phishing site presents an identical login page and intercepts the WebAuthn call — the origin check is enforced inside the authenticator, not in JavaScript, and cannot be bypassed by a man-in-the-middle who controls the network or the browser DOM. This property is what makes FIDO2 phishing-resistant by construction, whereas TOTP, SMS OTP, and push-notification MFA are all interceptable by a real-time phishing proxy. FIDO2 is the direct successor to FIDO U2F (Universal 2nd Factor), which provided phishing resistance as a second factor only; FIDO2 extends the model to full passwordless primary authentication.
fapolicyd (File Access Policy Daemon) is an application allowlisting framework for Linux, developed by Red Hat and shipped as a supported component of RHEL 8+. Its security premise is supply-chain integrity at the execution layer: only software that was installed through a trusted package manager (DNF/RPM) or explicitly declared as trusted by an administrator may execute on the system. An attacker who achieves a foothold and drops a new binary — a reverse shell, a lateral movement tool, a cryptominer — will find that binary blocked at execution time, because it is absent from the trust database, regardless of its Unix permissions or SELinux label. fapolicyd addresses a different dimension of access control than SELinux: SELinux models how applications behave (what resources they may access); fapolicyd models whether applications are trusted at all (whether they may execute in the first place). The two are complementary: SELinux confines a trusted application’s behaviour; fapolicyd prevents untrusted applications from running.
External Secrets Operator (ESO) is a CNCF incubating project that bridges the gap between Kubernetes-native secrets and enterprise secret management backends. Its premise is that native Kubernetes Secrets — base64-encoded values stored in etcd — are not adequate as a primary secret store: they offer no encryption at rest by default, no access audit trail, no versioning or rotation lifecycle, and no single source of truth across multiple clusters. Rather than replacing Kubernetes Secrets as a consumption mechanism (applications still mount them as environment variables or files in the familiar way), ESO replaces etcd as their source of authority, pulling the real values from a backend that does provide those properties and keeping the Kubernetes Secret as a synchronised, ephemeral projection.
eBPF (Extended Berkeley Packet Filter) is a Linux kernel subsystem, its modern form dating to kernel 3.18 (2014), that allows user-authored programs to run inside the kernel with near-native performance, subject to safety guarantees enforced at load time by a verifier. The name is historical: the original BPF (Berkeley Packet Filter, 1992) was a narrow packet filtering mechanism for tools like tcpdump. eBPF extended the instruction set, registers, and capabilities far beyond packet filtering into a general-purpose in-kernel programmability platform. The central design constraint is that eBPF programs must be provably safe: they cannot crash the kernel, loop infinitely, or access memory out of bounds. The verifier statically analyses every program at load time, checking that all memory accesses are bounds-checked, all loops are bounded or unrolled, and all pointer dereferences are preceded by null checks. Only programs that pass verification are accepted; once accepted, the kernel JIT-compiles the eBPF bytecode to native machine code for the host architecture — x86-64, ARM64, RISC-V — so eBPF programs run at the same speed as compiled kernel code, not as an interpreter.
CVSS (Common Vulnerability Scoring System) is an open framework published by FIRST (Forum of Incident Response and Security Teams) for characterising and communicating the technical severity of software vulnerabilities through a standardised numerical score. The current version is CVSS v4.0 (released November 2023), which introduced a fourth metric group and clarified nomenclature to address the persistent misuse of CVSS Base scores as standalone risk measurements. CVSS scores appear in the NVD (National Vulnerability Database), CVE entries, scanner output from Qualys, Tenable, Rapid7, Grype, and Trivy, and in compliance frameworks that specify remediation SLAs based on severity bands — “critical (9.0–10.0) within 15 days, high (7.0–8.9) within 30 days.” The score ranges from 0.0 (no impact) to 10.0 (maximum severity) and maps to five qualitative ratings: None (0.0), Low (0.1–3.9), Medium (4.0–6.9), High (7.0–8.9), and Critical (9.0–10.0).
A Certificate Revocation List (CRL) is a signed data structure, published by a Certificate Authority as part of its PKI operations, that lists the serial numbers of X.509 certificates the CA has revoked before their scheduled expiry date. A CA revokes a certificate when its private key is compromised, the subject’s identity information changes, the certificate was mis-issued, or the subject is no longer authorised. Without revocation, a compromised certificate remains trusted by all verifiers until it expires — which for long-lived CA and infrastructure certificates can be years. The CRL is the oldest revocation mechanism, defined in RFC 5280 alongside the X.509 v3 certificate format, and remains widely deployed for CA certificates, code signing certificates, and client certificates in contexts where OCSP is impractical.
A Confidential VM (CVM) is a virtual machine in which the guest’s memory contents, CPU register state, and execution flow are hardware-encrypted and isolated from everything outside it: the hypervisor, the host operating system, the cloud operator, other tenants, and anyone with physical access to the machine. The isolation is enforced not by software policy but by the CPU itself, using TEE technology — Intel TDX, AMD SEV-SNP, or Arm CCA — so that no amount of privilege on the host side grants access to the guest’s private state. A CVM is the VM-granularity equivalent of what SGX enclaves provide at the process level: the key difference is that a CVM requires no application changes, making it the practical path for lifting existing workloads into a confidential computing environment.
A Confidential GPU is a GPU whose memory, computation state, and data transfers are hardware-encrypted and isolated from the host system — extending the Trusted Execution Environment (TEE) boundary that technologies like TDX and SEV-SNP provide at the CPU level to encompass the GPU accelerator as well. The primary implementation today is NVIDIA Confidential Computing on the Hopper architecture (H100 and later), which encrypts all data resident in GPU High Bandwidth Memory (HBM) using per-context keys managed by the GPU’s on-die security processor. This means that model weights, training data, activations, and intermediate computations are cryptographically protected throughout GPU processing — a host administrator, hypervisor, or co-tenant with DMA access to the PCIe bus sees only ciphertext. The GPU also participates in a dedicated attestation flow: the NVIDIA Remote Attestation Service (NRAS) produces signed evidence that a specific GPU is genuine NVIDIA hardware running in Confidential Computing mode with unmodified firmware, analogous to how Intel DCAP or AMD KDS attest CPU TEEs. This GPU attestation is verified alongside CPU attestation before secrets (model decryption keys, dataset credentials) are released to the combined CPU+GPU TEE. The technology requires no application code changes — existing TensorFlow, PyTorch, and CUDA workloads run unmodified inside the confidential boundary. The primary threat model is the same as CPU-level confidential computing (protecting data-in-use from the infrastructure operator) but applied to the specific risk of AI workloads: model intellectual property theft, training data exfiltration, and inference input/output interception during GPU computation.
Confidential Containers (CoCo) is a CNCF sandbox project that lifts hardware confidential computing — TDX, SEV-SNP, Intel SGX, IBM Secure Execution — up to the Kubernetes pod level, providing a unified software layer that abstracts away the underlying TEE technology. Its defining trust model is unusually strict: the Kubernetes control plane, the kubelet, the container runtime, and the cloud operator are all treated as explicitly untrusted. Only the hardware itself and the workload owner’s own supply chain are in scope for trust.
A Confidential Cluster is a Kubernetes cluster designed so that the cloud or infrastructure operator — including hypervisor administrators, datacenter staff, and anyone who can access the underlying hardware — is entirely outside the trusted computing base. It achieves this by running every Kubernetes node, including control plane nodes, as a Confidential VM, and by extending the confidential boundary to cover not just individual workloads but the cluster’s network traffic, persistent storage, and control plane state. The goal is that a workload owner can cryptographically verify the entire cluster before trusting it, and that no privileged party outside the cluster’s own CVMs can read or tamper with workload data, cluster secrets, or etcd contents.
composefs is a Linux filesystem technology created by Alexander Larsson and Giuseppe Scrivano at Red Hat that provides cryptographically verified, read-only filesystem trees with opportunistic file-level sharing across images. Its motivating problem is a gap that neither dm-verity nor plain overlayfs fills cleanly: dm-verity provides strong integrity over a whole block device but requires a self-contained disk image and cannot share files between images; overlayfs allows layered, shared filesystems but protects only file contents (via fs-verity) and not the directory structure or metadata — an attacker who can manipulate a file’s name, permissions, or position in the tree is not caught. composefs closes that gap by separately protecting content and metadata, then composing them at mount time.
cert-manager is a CNCF graduated project that brings PKI lifecycle management into Kubernetes as a first-class controller, eliminating the manual processes — CSR generation, CA submission, secret rotation, renewal tracking — that cause certificate-related outages in clusters that manage TLS manually. Its premise is that X.509 certificates should be declared as Kubernetes resources with the same GitOps-friendly, reconciliation-driven lifecycle as any other workload configuration: an operator declares the desired certificate, cert-manager continuously ensures that a valid, non-expired certificate matching that declaration exists and is stored in a Kubernetes Secret, and renews it automatically before expiry. The default renewal threshold is two-thirds of the certificate’s validity period, so a certificate with a 90-day lifetime is renewed at 60 days without operator intervention.
A break-glass user (or break-glass account, emergency access account) is a privileged account that exists outside the normal access control workflow — bypassing PAM approval gates, MFA requirements, or SSO dependencies — and is reserved for situations where those normal mechanisms are themselves unavailable or would prevent responding to a critical incident in time. The name is a physical analogy: like the fire alarm panel behind a pane of glass that reads break glass in emergency, the account is designed so that accessing it requires a deliberate, detectable act. It is not a convenience mechanism; it is an organisational safety net for scenarios such as an identity provider outage locking all administrators out of their own infrastructure, a PAM platform failing during an active incident, or a ransomware attack disabling the tooling needed to contain it.
A bastion host (also called a jump server or jump host) is a hardened server placed at the boundary between a public network and a protected private network, through which all administrative access to internal systems must pass. Rather than exposing every server, database, or network device directly to the internet or to operator workstations, the network is designed so that only the bastion host has a publicly reachable address; internal systems accept SSH or RDP connections only from the bastion’s IP. An administrator who needs to reach an internal host connects first to the bastion — authenticating with a key, certificate, or MFA — and then hops onward to the target from there. The bastion’s narrow exposure makes it a concentrated target, which is why it receives disproportionate hardening: a minimal OS with only the necessary services running, strict firewall rules, aggressive patch cadence, and comprehensive session logging. The name comes from military fortification: a bastion is a protruding element of a castle wall designed to be defended at all costs.
AppArmor (Application Armor) is a Mandatory Access Control (MAC) system implemented as a major LSM (Linux Security Module), developed originally by Immunix and now maintained by Canonical. It is the default MAC system on Ubuntu, Debian, and their derivatives, and the default container confinement mechanism for containerd and Docker on those distributions. Where SELinux assigns security labels to every object on the system and enforces policy based on label interactions, AppArmor takes a fundamentally different approach: it confines programs by filesystem path. A profile for nginx lists the specific file paths that nginx is allowed to read, write, and execute, the network operations it may perform, and the Linux capabilities it may use — anything not listed is denied. No relabelling of the filesystem is required and no extended attributes are set: AppArmor’s confinement decisions are made purely from the path of the file being accessed and the identity of the confined process. This path-based model makes AppArmor profiles far simpler to read, write, and audit than SELinux policy, and eliminates the mislabelled-file failure mode that is the most common SELinux operational problem.
AIDE (Advanced Intrusion Detection Environment) is a host-based intrusion detection tool that implements file integrity monitoring (FIM): it builds a baseline database capturing cryptographic hashes and metadata for every file it is configured to watch, and on subsequent runs compares the live filesystem against that database, reporting anything that has been added, removed, or changed. Its security premise is detection after the fact: AIDE does not prevent modifications (that is the role of fapolicyd, SELinux, and IMA), but it provides a reliable, auditable record that modifications occurred, when a check was run, and which specific attributes changed. An attacker who compromises a system and modifies a binary, a configuration file, a cron job, or an SSH authorized_keys file will leave a fingerprint in the next AIDE check — provided the database has not also been compromised, which is the central operational concern the tool’s deployment model must address.
