# Agentic Ai Projects And Mastery
All Agentic Ai Projects And Mastery notes →# Ci Cd
All Ci Cd notes →1 — Identity & Access Management
Covers identity and access management for a CI/CD platform — workload identity, human access, and the boundary between the two.
2 — Secret Management
Covers how a CI/CD platform stores, rotates, injects, and audits secrets used by pipelines and deployments.
3 — Policy as Code
Covers expressing security and compliance rules as versioned, testable policy-as-code enforced at pipeline gates.
4 — Secure Pipeline Design
Covers the design practices — least privilege, isolation, signed artifacts, hardened runners — that make a pipeline itself resistant to compromise.
5 — Software Supply Chain Security
Covers securing the end-to-end software supply chain from source to production — see kubernetes/08-supply-chain-security for SBOM, signing, and SLSA implementation detail.
6 — Compliance Automation
Covers automating compliance evidence collection and control enforcement directly inside the CI/CD platform rather than as a manual audit exercise.
7 — GitHub Actions: Authentication
Covers the GITHUB_TOKEN, fine-grained PATs, GitHub Apps, and OIDC federation to Azure, AWS, and GCP as the four authentication mechanisms available to a workflow.
8 — GitHub Actions: Secrets Management
Covers repository, organization, and environment secrets and variables, secret rotation, and least-privilege scoping for CI credentials.
9 — GitHub Actions: Secure Pipelines
Covers dependency review, CodeQL, secret scanning, artifact attestations, branch protection, required reviews, signed commits, and supply chain security gates enforced inside a workflow.
# Dbms
All Dbms notes →1 — Authentication & Authorization
Covers authentication and authorization in a DBMS via roles, privileges, and role-based access control.
2 — Encryption
Covers encryption at rest, encryption in transit, and transparent data encryption (TDE).
3 — SQL Injection
Covers SQL injection prevention through prepared statements and safe ORM usage.
# Kubernetes
All Kubernetes notes →1 — Pod Security Standards
Pod Security Standards replaced the removed PodSecurityPolicy admission controller with three built-in profiles (Privileged, Baseline, Restricted) enforced declaratively via namespace labels.
10 — Protecting the Control Plane
Because etcd stores every cluster secret unencrypted by default, encryption at rest, mutual TLS between control plane components, and tightly scoped RBAC on kube-system are the highest-leverage hardening steps, not just API server firewalling.
2 — Security Contexts
A securityContext can be set at both pod and container level to drop capabilities, force non-root execution, or make the root filesystem read-only, and container-level fields always override pod-level defaults.
3 — Seccomp
Seccomp filters which syscalls a container's process is allowed to make at the kernel level, and the RuntimeDefault profile alone blocks dozens of dangerous syscalls that ordinary application workloads never legitimately need.
4 — AppArmor
AppArmor confines a process with path-based file, network, and capability rules rather than syscall filtering, and since Kubernetes 1.30 it is configured as a first-class securityContext field instead of only through legacy annotations.
5 — SELinux
SELinux enforces mandatory access control by comparing security-context labels on processes and objects rather than relying on discretionary Unix permissions, and label mismatches are the most common cause of unexplained permission-denied errors in hardened clusters.
6 — Capabilities
Linux capabilities split root's monolithic power into roughly forty discrete privileges, so dropping ALL and adding back only what's needed, like NET_BIND_SERVICE, is a far narrower grant than running the container as root.
7 — Linux Kernel Isolation
Containers isolate processes using namespaces and cgroups on a single shared host kernel rather than virtualizing hardware, so a kernel-level exploit inside one container can compromise every other container scheduled on that node.
8 — RuntimeClass
RuntimeClass lets a pod select a different container runtime, such as runc, gVisor, or Kata, so untrusted or multi-tenant workloads can get stronger isolation without changing the cluster-wide default runtime for every other workload.
9 — Sandboxed Containers (gVisor, Kata)
gVisor intercepts syscalls through a userspace kernel while Kata runs each pod inside a lightweight VM, and both trade some raw performance for a dramatically smaller attack surface than a shared-kernel container runtime.
# Networks
All Networks notes →1 — Cryptography Fundamentals
Symmetric and asymmetric encryption, hashing, and HMAC as the cryptographic primitives every later security chapter depends on.
3 — HTTPS
Certificate validation, HSTS, OCSP, and session resumption as the mechanics that turn TLS into HTTPS in practice.
4 — Authentication Protocols
OAuth2, OIDC, JWT, SAML, and Kerberos as the authentication protocols that show up repeatedly in distributed-systems interviews.
5 — Network Security
VPNs, IPSec, WAFs, IDS/IPS, and DDoS protection as the network-level security controls layered on top of TLS.
# Observability
All Observability notes →1 — RBAC
Covers role-based access control for telemetry — who can query which tenant or team’s data, and at what granularity.
2 — Multi Tenancy
Covers the isolation guarantees a shared observability platform must enforce so one tenant can never read another’s telemetry.
3 — Data Privacy
Covers the privacy obligations that apply to telemetry data specifically, distinct from the privacy obligations on the underlying application data.
4 — PII Redaction
Covers how PII ends up in telemetry by accident (log lines, span attributes, user IDs) and where in the pipeline to catch it.
6 — Audit Logging
Covers the query audit log — who ran what query against what data — as security telemetry about the platform itself.
7 — Secret Management
Covers keeping API keys, tokens, and credentials out of telemetry payloads and out of collector/exporter configuration in plaintext.
# Operating System
All Operating System notes →# Sre
All Sre notes →1 — Identity and Access Management
Who can do what, to which system, and how that access is granted, reviewed, and revoked — the control plane every other security chapter in this Part depends on.
10 — Business Continuity
The organizational plan for keeping the business running through a disaster, of which technical disaster recovery is only one component.
2 — Secrets Management
Why a secret hardcoded in a config file or env var is a standing incident waiting for a git history search, and the vault-backed rotation that closes that gap.
3 — Zero Trust
Verifying every request regardless of network origin, on the assumption the perimeter is already compromised — and what that means for how services actually authenticate to each other.
4 — Network Security
Segmentation, firewalling, and the assumption that lateral movement is possible the moment any single node is compromised.
5 — Kubernetes Security
RBAC, pod security standards, and network policies — the layers that keep a compromised container from becoming a compromised cluster.
6 — Runtime Security
Detecting anomalous behavior in a running workload — the security signal that exists only after static scanning and admission control have already passed.
7 — Incident Response for Security
Why a security incident's containment-first response differs from a reliability incident's restore-service-first one, and where the two response models collide.
8 — Compliance
Where audit and regulatory obligations intersect with the reliability practice — access logs, retention policies, and the postmortem review process itself.
9 — Disaster Recovery
RTO and RPO as the two numbers that actually define a DR plan, and the difference between a plan that exists on paper and one that's been tested.
# System Design
All System Design notes →Chapter 1 — Identity: OAuth, OIDC, JWT, SPIFFE, mTLS
The identity stack for humans and workloads — OAuth/OIDC for users, JWTs as bearer tokens, SPIFFE/mTLS for service-to-service trust.
Chapter 2 — Security Architecture & Zero Trust
Zero trust, secrets management, and encryption/KMS as the assumption that the network perimeter was never actually the security boundary.
Authentication at the Ingestion Frontier: mTLS, Bearer Tokens, API Keys
How the gateway proves an agent's credential is valid — mTLS handshake validation, JWT bearer token signature checks, and API key lookups — with the revocation-speed vs operational-complexity trade-off between them, and credential rotation at 10M-agent scale.
Q11: Redesigning the Ingestion Frontier for a Compromised-Agent Threat Model
Full principal-level solution: redesign the telemetry ingestion frontier assuming a compromised agent sends malformed and adversarial payloads — oversized batches, spoofed tenant IDs, garbage label values.