-
Notifications
You must be signed in to change notification settings - Fork 0
EN_IT_Security
One-line answer: A security model built on "never trust, always verify" — authenticating, authorizing, and encrypting every request regardless of network location, and enforcing least privilege.
Zero Trust is a security model built on the core philosophy of "never trust, always verify." No user, device, or workload is automatically trusted simply because it sits inside the network; every access request is explicitly verified, every time. The U.S. NIST publication NIST SP 800-207 (Zero Trust Architecture) is the de facto standard definition document.
Traditional security followed the castle-and-moat model, treating everything inside the firewall perimeter as a "trusted zone." But with the spread of cloud, remote work, and microservices, the "inside/outside" boundary blurred, and a single breached perimeter let attackers move laterally through the internal network freely. Zero Trust responds by refusing to trust that perimeter at all.
- Verify Explicitly: Authenticate and authorize every request based on all available signals — user identity, device posture, location, request context, and more.
- Least-Privilege Access: Grant only the access needed, only for as long as needed (JIT/JEA).
- Assume Breach: Operate as if already compromised and minimize the blast radius — microsegmentation, encryption, and continuous monitoring.
| Aspect | Perimeter Security | Zero Trust |
|---|---|---|
| Trust assumption | Trust inside, distrust outside | Distrust regardless of location |
| Verification point | Once, at the perimeter | Continuously, on every request |
| Lateral movement | Free inside once perimeter is breached | Blocked per segment |
| Permission model | Broad network access | Least privilege, per-resource |
| Best fit | On-prem, fixed perimeter | Cloud, remote, hybrid |
- Identity: Strong authentication (MFA) for user and service accounts, identity-based policy
- Device: Device registration and posture checks (patching, EDR), block non-compliant endpoints
- Network/Segmentation: Microsegmentation to subdivide traffic
- Application: Per-application access control, inline authorization
- Data: Data classification, encryption, and access control
A technique that divides the network into small zones at the workload/application level, defaults to blocking traffic between zones (default-deny), and allows only explicitly permitted traffic through. Even if one workload is compromised, it prevents lateral movement to adjacent workloads, reducing the blast radius.
An approach that replaces the traditional VPN. Instead of putting a user "on the network," it brokers access only to specific applications. Users can see only the applications they are authorized for — not the entire network — eliminating the broad internal exposure that VPNs create.
Google's BeyondCorp is the canonical large-scale Zero Trust implementation. It removes "being on the corporate network (VPN)" as a basis for trust and instead authorizes every access based on user identity plus device trust. An employee goes through the same verification whether inside the office network or at a coffee shop — trust comes from identity and device posture, not network location.
One-line answer: RBAC bundles permissions into roles granted to subjects, Least Privilege is the principle of granting only the permissions actually needed, and IAM is the system that manages these identities and permissions.
Instead of granting permissions directly to users, RBAC bundles permissions into roles and assigns roles to users. By defining permission sets for roles like "developer," "operator," or "read-only," onboarding a new person becomes a matter of assigning a role, making access management simple and consistent. Managing permissions per individual user scatters access and leads to missed revocations as scale grows.
| Aspect | RBAC | ABAC (Attribute-Based) |
|---|---|---|
| Decision basis | Role | Attributes — user, resource, environment |
| Example policy | "Operator role can deploy" | "dept=finance AND time=business-hours AND location=office" |
| Flexibility | Low, simple | High, fine-grained |
| Management complexity | Low | High |
| Best fit | Organizations with clear roles | Dynamic, context-based authorization |
The principle of granting each subject (user, service, process) only the minimum permissions required to do its job. Excessive permissions are an attack surface — when an account is compromised or misused, the damage scales with the granted scope. Broad "just in case" permissions (over-privileged access) are one of the most common security flaws.
The principle of splitting permissions so that no single person can perform the entire lifecycle of a sensitive operation alone. For example, separating who requests a deployment from who approves it, or the code author from the production-merge approver. This reduces the impact of insider threats and single mistakes.
A system that centrally defines, enforces, and audits "who (Identity) accesses what (Resource) with which permissions (Permission)." It encompasses both authentication (verifying identity) and authorization (granting permission), with cloud IAMs like AWS IAM, GCP IAM, and Azure AD being representative. RBAC, least privilege, and separation of duties are all policies implemented within IAM.
Kubernetes defines permissions in a Role (namespace-scoped) or ClusterRole (cluster-scoped) and binds them to subjects via RoleBinding / ClusterRoleBinding. Below is a least-privilege example that allows read-only access to Pods in the default namespace.
# Role: defines read-only permissions for Pods in the default namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""] # "" is the core API group
resources: ["pods"]
verbs: ["get", "watch", "list"]
---
# RoleBinding: binds the Role above to a specific user
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
- kind: User
name: jane # actual user identifier (example value)
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.ioCarelessly granting a broad role like cluster-admin to a service account means that if that workload is compromised, the entire cluster is exposed. Permissions should be designed to be "added when needed" (deny-by-default), and unused permissions should be revoked periodically (access reviews).
One-line answer: mTLS is bidirectional TLS where client and server mutually authenticate with certificates, and PKI is the trust system (CA) that manages certificate issuance, verification, and revocation.
TLS (Transport Layer Security) is the standard protocol that encrypts client–server communication and authenticates the server's identity. Typical HTTPS uses one-way TLS: the client verifies the server's certificate, but the server does not verify the client's identity via certificate.
mTLS (mutual TLS) is the approach where both sides present certificates and verify each other mutually. The server verifies the client and the client verifies the server via certificates, so only workloads with trusted certificates can communicate with each other.
| Aspect | TLS (one-way) | mTLS (mutual) |
|---|---|---|
| Server authentication | Yes | Yes |
| Client authentication | No (separate mechanism) | Yes (via certificate) |
| Main use | Web/browser HTTPS | Service-to-service, Zero Trust |
The standard certificate format, containing a public key, its owner (subject) information, the issuer, a validity period, and a signature. The communicating party verifies the certificate's signature to trust that "this public key really belongs to this subject."
- CA (Certificate Authority): A trusted authority that issues and signs certificates
- Root CA: The top-level anchor of trust. Self-signed and pre-installed in OSes and browsers
- Intermediate CA: A CA signed by the Root; actual issuance is usually delegated to intermediate CAs
-
Chain of Trust: The signing chain
end-entity certificate → Intermediate CA → Root CA. The verifier walks up this chain, and once it reaches a trusted Root, it trusts the certificate.
- CA: Issues and signs certificates
- RA (Registration Authority): Verifies the identity of the requesting party
- Certificate store/distribution: Stores and distributes issued certificates
- CRL / OCSP: The Certificate Revocation List of revoked certificates, and real-time revocation status checking (OCSP)
Certificates have a validity period and must be renewed (rotated) before expiry. Leaving a certificate to expire can cause a major outage that severs all communication. Short-lived certificates plus automated rotation is the best practice, and tools like cert-manager automate issuance and renewal in Kubernetes.
Service meshes like Istio and Linkerd inject a sidecar proxy into each pod to automatically encrypt and authenticate service-to-service traffic with mTLS. The mesh handles certificate issuance, rotation, and verification without any application code changes, making it easy to apply mutual authentication across all internal (east-west) traffic in a cluster.
Since Zero Trust holds that "even the internal network is not trusted," service-to-service (east-west) communication must also be authenticated and encrypted. mTLS gives each workload a verifiable identity (a certificate) and encrypts all internal communication, making it the key mechanism that realizes Zero Trust's "verify explicitly" principle at the network layer.
One-line answer: OAuth 2.0 is a delegation (authorization) protocol that issues access tokens, and OIDC adds an identity layer (ID token) on top to also provide authentication.
- OAuth 2.0 is an authorization framework. It focuses on delegating "may this application access a specific resource on the user's behalf?" It issues a token with limited permissions without exposing the user's password to a third-party app.
- OIDC (OpenID Connect) is a thin authentication layer on top of OAuth 2.0. It verifies "who is this user?" and additionally issues an ID Token containing identity information.
| Aspect | OAuth 2.0 | OIDC |
|---|---|---|
| Main purpose | Authorization | Authentication |
| Question answered | "What can be accessed?" | "Who is this user?" |
| Tokens issued | Access Token, Refresh Token | + ID Token (JWT) |
| Foundation | Standalone standard | Extension of OAuth 2.0 |
| Typical use | API access delegation | SSO login, identity verification |
- Authorization Code + PKCE: The most recommended flow. The user logs in at the authorization server, receives a temporary authorization code, and exchanges it for a token. PKCE (Proof Key for Code Exchange) is an extension that prevents code interception and is mandatory for public clients such as SPAs and mobile apps.
- Client Credentials: Used for machine-to-machine communication with no user involved. The client obtains a token directly using its client ID/secret.
Note: The Implicit and Resource Owner Password Credentials grants are no longer recommended for security reasons and are effectively deprecated.
- Access Token: A short-lived token used to access resources. Typically has a short lifetime.
- Refresh Token: A longer-lived token used to obtain a new access token once the access token expires. Must be stored securely.
- ID Token: The token OIDC adds, containing user identity claims, in the form of a JWT (JSON Web Token).
The range of permissions a token grants. For example: openid profile email, read:repo. It is the means of implementing least privilege at the OAuth layer — an app should request only the minimum scopes it needs.
OIDC's ID Token is itself the JWT format covered in another entry — a header.payload.signature structure carrying user claims (sub, email, exp, etc.). OIDC is also the modern standard for implementing SSO (covered in another entry), propagating authentication to multiple applications from a single identity provider (IdP) login.
One-line answer: Separating secrets like passwords, API keys, and certificates from code to store, rotate, and access-control them securely — using tools like Vault and AWS Secrets Manager.
Embedding secrets like API keys, DB passwords, and tokens directly into source code, config files, or container images is the most common and dangerous anti-pattern. Once committed to git, a secret lives forever in history, so it remains exposed even if you later delete the file. Never commit secrets to git is the first rule.
A representative tool for centrally storing, issuing, and auditing secrets.
- Static Secrets: Provide a pre-stored value (e.g., an API key) to an authorized subject.
- Dynamic Secrets: Short-lived secrets generated on the fly at request time. For example, when a DB access request comes in, it creates a temporary DB account on the spot and automatically revokes it after a set period.
- Lease & Rotation: Assign a lease period to every secret and automatically rotate/revoke it on expiry. Even if a secret leaks, its short lifetime limits the damage.
The native Kubernetes Secret is stored in etcd as base64 (effectively plaintext), so it cannot be put in git as-is. Sealed Secrets (Bitnami) encrypts a secret with the cluster controller's public key, producing a SealedSecret resource — this ciphertext is safe to commit to git, and only the controller inside the cluster can decrypt it into an actual Secret. It fits GitOps well.
An operator that treats a secret store outside Kubernetes (Vault, AWS Secrets Manager, GCP Secret Manager, etc.) as the single source of truth and automatically syncs those values into Kubernetes Secrets. The secret originals stay outside the cluster, and Kubernetes only references them.
Encrypting stored data so that even if a disk or backup is stolen, plaintext is not exposed. A KMS (Key Management Service) is a service (AWS KMS, GCP Cloud KMS, etc.) that securely generates, stores, and rotates the encryption keys themselves. Envelope encryption is common: data is encrypted with a data key, which is itself encrypted with a master key held in the KMS.
A policy of periodically replacing secrets (or immediately upon suspected exposure). Make automatic rotation the default; combining short lifetimes with dynamic secrets minimizes the "useful lifetime of a stolen secret."
Core principle: Never commit secrets to git. If you commit one by mistake, immediately revoke/rotate that secret, and treat it as already exposed even after removing it from history.
One-line answer: DevSecOps that verifies integrity across the whole code-dependency-build-deploy chain (SBOM, signing, scanning) and shifts security left in the pipeline to defend against supply-chain attacks.
DevSecOps is the culture and practice of integrating security into the entire development process rather than as a separate final gate in the DevOps pipeline. The key is shift-left — moving security verification earlier into development (the coding and build stages) instead of just before deployment, catching defects cheaply and quickly. Security is treated as "everyone's responsibility" and baked into the pipeline through automation.
A "list of ingredients" enumerating all the components, dependencies, and versions a piece of software contains. Knowing which library went in at which version lets you immediately assess the blast radius when a new vulnerability (CVE) is disclosed. CycloneDX and SPDX are the widely used standard formats.
A framework that defines supply-chain integrity in levels, structured to progressively guarantee more strongly that a build has not been tampered with (roughly L1 → L4).
- L1: Documented build process, provenance generated
- L2: Hosted build service + signed provenance
- L3: Hardened, tamper-resistant build platform, forged provenance blocked
- L4 (highest): The strongest guarantees, such as two-person review and reproducible builds
Sigstore is an open-source ecosystem for signing and verifying software artifacts (such as container images). Signing an image with cosign lets you verify the provenance that "this image really came out of our pipeline," preventing the deployment of tampered or forged images. It also supports keyless signing.
| Type | Full name | When/what it checks | One-line description |
|---|---|---|---|
| SAST | Static Application Security Testing | Source code (not running) | Statically analyzes code to detect vulnerable patterns |
| DAST | Dynamic Application Security Testing | Running app (black-box) | Simulates real attacks from outside to find vulnerabilities |
| SCA | Software Composition Analysis | Open-source dependencies | Checks libraries in use for known CVEs |
| IAST | Interactive Application Security Testing | Instrumented inside the running app | Hybrid of SAST+DAST, observing code flow at runtime |
-
CVE (Common Vulnerabilities and Exposures): A unique identifier assigned to a publicly disclosed vulnerability. The format is
CVE-YYYY-NNNNN(e.g.,CVE-2021-44228). It lets the whole world refer to the same vulnerability with the same ID. - CVSS (Common Vulnerability Scoring System): Quantifies a vulnerability's severity on a 0.0 – 10.0 scale. Severity bands by score:
| CVSS Score | Severity |
|---|---|
| 0.0 | None |
| 0.1 – 3.9 | Low |
| 4.0 – 6.9 | Medium |
| 7.0 – 8.9 | High |
| 9.0 – 10.0 | Critical |
A list, published periodically by OWASP (Open Worldwide Application Security Project), of the 10 most dangerous and common security risks in web applications (e.g., Broken Access Control, Injection, Cryptographic Failures). It serves as the de facto checklist for web security and is widely used as a baseline for scanning and code review in DevSecOps pipelines.