Skip to content

Instantly share code, notes, and snippets.

View sozercan's full-sized avatar
:shipit:
I may be slow to respond.

Sertaç Özercan sozercan

:shipit:
I may be slow to respond.
View GitHub Profile
BEGIN:VCALENDAR
METHOD:PUBLISH
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:tzone://Microsoft/Utc
BEGIN:STANDARD
DTSTART:16010101T000000
TZOFFSETFROM:+0000
TZOFFSETTO:+0000
@sozercan
sozercan / github_api_summary.md
Created April 22, 2026 00:06
PR4504 GitHub API summary for Codex citation

GitHub API checks for open-policy-agent/gatekeeper PR #4504 Fetched on 2026-04-22 UTC using gh pr view and gh api graphql.

PR metadata:

  • title: fix: avoid externaldata provider status reconcile loop
  • state: MERGED
  • mergedAt: 2026-04-22T00:02:27Z
  • reviewDecision: APPROVED
  • url: open-policy-agent/gatekeeper#4504
  • mergeCommit: 4d78cc96735268f8ebd89112767d206d3669b32c
@sozercan
sozercan / eraser-threat-model.md
Created April 10, 2026 18:16
eraser threat model

Overview

Eraser is a Kubernetes operator that cleans container images from nodes. It runs a controller-manager (main.go, controllers/*) that watches cluster-scoped CRDs (ImageList and ImageJob in api/v1) and manages per-node cleanup pods. It supports two modes: manual cleanup via ImageList (imagelist controller builds a ConfigMap with the supplied list and spawns remover pods), and automated cleanup via scheduled ImageJob runs (imagecollector controller creates a pod template with collector, optional scanner, and remover containers). The collector enumerates non-running images via the container runtime (pkg/collector, pkg/cri) and passes JSON lists over named pipes to the scanner/remover (pkg/utils, pkg/scanners/template). The remover deletes images from the CRI socket (pkg/remover). Configuration is provided via an EraserConfig YAML stored in a ConfigMap and mounted into the manager (api/unversioned, main.go). The manager watches the file with inotify and can restart if component enablement changes. Helm

@sozercan
sozercan / gk-threat-model.md
Created April 10, 2026 18:15
gatekeeper threat model

Overview

Gatekeeper is a Kubernetes admission controller and policy enforcement system built on Open Policy Agent (OPA). It runs as a controller manager inside the cluster, exposes validating and mutating webhooks, reconciles CRDs for ConstraintTemplates, Constraints, Mutators, and external data Providers, performs periodic audits, and optionally exports audit results. Runtime entrypoints are in main.go, with core admission logic in pkg/webhook/ and policy engines in the OPA and CEL drivers. A separate CLI (cmd/gator) supports local testing and OCI bundle ingestion.

Gatekeeper is security-critical because it sits in the admission path for all Kubernetes resource creation/updates. It typically runs with broad read access to cluster objects and with permissions to manage webhook configuration, CRDs, and status resources. Misconfiguration or vulnerabilities can cause policy bypass, denial of service, or cluster-wide impact.

Threat model, Trust boundaries and assumptions

Trust boundaries

  • Kuber
Overview
Project Copacetic (copa) is a Go CLI and optional BuildKit frontend that patches existing container images directly. It parses vulnerability scan reports (Trivy or a custom copa-<scanner> plugin), builds an update manifest, downloads OS and language package updates, and applies those updates via BuildKit to produce a patched image. It can patch single or multi-arch images, push to registries or export OCI layouts, and generate VEX documents (pkg/generate, pkg/vex). The tool is typically run in CI/CD or by security operators with registry credentials and access to a trusted BuildKit daemon. It is not a network service and does not include user authentication or multi-tenant isolation by itself.
Threat model, Trust boundaries and assumptions
Trust boundaries
Host environment: the machine running copa holds filesystem access, registry credentials, and executes helper binaries (docker, podman, tar, copa-<scanner>). Compromise here is severe.
BuildKit daemon/worker: executes update commands inside con
@sozercan
sozercan / setup-amlfs-aks.sh
Last active March 13, 2026 03:43
Enable Azure Managed Lustre File System (AMLFS) on an existing AKS cluster with dynamic provisioning
#!/usr/bin/env bash
#
# setup-amlfs-aks.sh
#
# Enable Azure Managed Lustre File System (AMLFS) on an existing AKS cluster
# with dynamic provisioning via the Azure Lustre CSI driver.
#
# IMPORTANT: AMLFS requires a dedicated subnet separate from the AKS node subnet.
# This script automatically creates one if it doesn't exist. Using the AKS node
# subnet causes extremely slow provisioning (90+ min vs ~15 min with a dedicated subnet).
apiVersion: ray.io/v1
kind: RayService
metadata:
name: qwen
spec:
serveConfigV2: |
applications:
- name: llm_app
import_path: ray.serve.llm:build_openai_app
route_prefix: "/"
apiVersion: ray.io/v1
kind: RayService
metadata:
name: qwen-disaggregated
spec:
serveConfigV2: |
applications:
- name: pd-disaggregation
import_path: ray.serve.llm:build_pd_openai_app
route_prefix: "/"
oss-gpt120b-bench-j9b29 Collecting ruamel-yaml~=0.18.12 (from aiperf==0.1.1)
oss-gpt120b-bench-j9b29 Downloading ruamel.yaml-0.18.15-py3-none-any.whl.metadata (25 kB)
oss-gpt120b-bench-j9b29 Collecting setproctitle~=1.3.6 (from aiperf==0.1.1)
oss-gpt120b-bench-j9b29 Downloading setproctitle-1.3.7-cp312-cp312-manylinux1_x86_64.manylinux_2_28_x86_64.manylinux_2_5_x86_64.whl.metadata (10 kB)
oss-gpt120b-bench-j9b29 Collecting soundfile~=0.13.1 (from aiperf==0.1.1)
oss-gpt120b-bench-j9b29 Downloading soundfile-0.13.1-py2.py3-none-manylinux_2_28_x86_64.whl.metadata (16 kB)
oss-gpt120b-bench-j9b29 Collecting textual~=5.3.0 (from aiperf==0.1.1)
oss-gpt120b-bench-j9b29 Downloading textual-5.3.0-py3-none-any.whl.metadata (9.1 kB)
oss-gpt120b-bench-j9b29 Collecting tqdm>=4.67.1 (from aiperf==0.1.1)
oss-gpt120b-bench-j9b29 Downloading tqdm-4.67.1-py3-none-any.whl.metadata (57 kB)