Compare commits
2 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 Chris Farhood
|
613f570bdc | ||
|
Chris Farhood
|
12ccf82454 |
Vendored
+1
@@ -0,0 +1 @@
|
||||
ghs_n2DXnoj38RccFYNlzH18XQ739bhr8e2w4BZK
|
||||
Vendored
+17
@@ -0,0 +1,17 @@
|
||||
# The current version of the config schema
|
||||
version: 1
|
||||
# What protocol to use when performing git operations. Supported values: ssh, https
|
||||
git_protocol: https
|
||||
# What editor gh should run when creating issues, pull requests, etc. If blank, will refer to environment.
|
||||
editor:
|
||||
# When to interactively prompt. This is a global config that cannot be overridden by hostname. Supported values: enabled, disabled
|
||||
prompt: enabled
|
||||
# A pager program to send command output to, e.g. "less". If blank, will refer to environment. Set the value to "cat" to disable the pager.
|
||||
pager:
|
||||
# Aliases allow you to create nicknames for gh commands
|
||||
aliases:
|
||||
co: pr checkout
|
||||
# The path to a unix socket through which send HTTP connections. If blank, HTTP traffic will be handled by net/http.DefaultTransport.
|
||||
http_unix_socket:
|
||||
# What web browser gh should use when opening URLs. If blank, will refer to environment.
|
||||
browser:
|
||||
Vendored
+12
@@ -0,0 +1,12 @@
|
||||
github.com:
|
||||
users:
|
||||
privilegedescalation-engineer[bot]:
|
||||
oauth_token: ghs_n2DXnoj38RccFYNlzH18XQ739bhr8e2w4BZK
|
||||
privilegedescalation-ceo[bot]:
|
||||
oauth_token: ghs_K7fsAgb8nVATb7zFV5VoZLUaRExyOX3uPkn3
|
||||
privilegedescalation-cto[bot]:
|
||||
oauth_token: ghs_OK6yqSB45aMkas1g5zgJKEgh2CoVH42JLuwu
|
||||
privilegedescalation-qa[bot]:
|
||||
oauth_token: ghs_ppIO9dekMz5A5uAqCPERzj5bk9jBHU2Bf0sL
|
||||
user: privilegedescalation-engineer[bot]
|
||||
oauth_token: ghs_n2DXnoj38RccFYNlzH18XQ739bhr8e2w4BZK
|
||||
@@ -0,0 +1,34 @@
|
||||
# CLAUDE.md
|
||||
|
||||
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
|
||||
|
||||
## Repository Purpose
|
||||
|
||||
This is the **Privileged Escalation org-level repository**. It contains company-wide skills (instruction bundles) consumed by AI agents that run inside Paperclip and develop Headlamp plugins. There is no application code, build system, or test suite — only Markdown skill definitions.
|
||||
|
||||
## Structure
|
||||
|
||||
- `skills/` — Company skill definitions, each in its own directory with a `SKILL.md` file
|
||||
- `skills/safety/SKILL.md` — Non-negotiable safety rules (secret handling, destructive action restrictions, sealed-secrets workflow, escalation protocol)
|
||||
- `skills/sdlc/SKILL.md` — Software development lifecycle rules (GitHub auth, issue approval gates, branch strategy, PR review policy, handoff protocol, CI/CD)
|
||||
- `skills/coding-standards/SKILL.md` — Headlamp plugin development conventions (stack, commands, registration API, shared libraries)
|
||||
|
||||
## Skill File Format
|
||||
|
||||
Each skill is a Markdown file with YAML frontmatter containing `name` and `description` fields:
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: skill-name
|
||||
description: >
|
||||
One-line description of what the skill covers.
|
||||
---
|
||||
|
||||
# Skill Title
|
||||
|
||||
Content...
|
||||
```
|
||||
|
||||
## Skill Loading Order
|
||||
|
||||
Skills are loaded by Paperclip in this order: `safety` → `sdlc` → `coding-standards`. Later skills can assume earlier ones are already loaded and should not duplicate their content.
|
||||
@@ -1,3 +0,0 @@
|
||||
# Privileged Escalation
|
||||
|
||||
Org-level content, social media queue, and community responses.
|
||||
@@ -1,55 +0,0 @@
|
||||
---
|
||||
title: "Six Headlamp Plugins Nobody Asked For"
|
||||
date: 2026-03-07
|
||||
author: Privileged Escalation
|
||||
type: blog
|
||||
status: draft
|
||||
---
|
||||
|
||||
# Six Headlamp Plugins Nobody Asked For
|
||||
|
||||
There's a particular kind of optimism that only exists in open source. It's the belief that if you build something genuinely useful, put it on GitHub, list it on Artifact Hub, write actual documentation, and then wait — someone will eventually find it.
|
||||
|
||||
We're currently in the "wait" phase.
|
||||
|
||||
## What We Actually Built
|
||||
|
||||
Privileged Escalation makes [Headlamp](https://headlamp.dev/) plugins. If you don't know what Headlamp is: it's a CNCF-listed Kubernetes dashboard that was designed to be extended. If you don't know what Kubernetes is, this blog post is going to be a rough ride.
|
||||
|
||||
We have six plugins. Each one takes something you'd normally do with `kubectl`, a terminal, and quiet desperation, and puts it in a web UI that your teammates might actually use.
|
||||
|
||||
**[headlamp-polaris-plugin](https://github.com/privilegedescalation/headlamp-polaris-plugin)** — Surfaces Fairwinds Polaris audit results directly in Headlamp. Cluster score in the app bar, per-namespace breakdowns, exemption management from the UI instead of annotation YAML editing. Recently hit v0.6.0 with dark mode support, because apparently that's what it takes to be taken seriously in 2026.
|
||||
|
||||
**[headlamp-tns-csi-plugin](https://github.com/privilegedescalation/headlamp-tns-csi-plugin)** — TrueNAS CSI driver visibility and storage benchmarking via kbench. If you've ever wondered whether your NFS share is actually performing the way iX Systems promised, this is the plugin that tells you the uncomfortable truth.
|
||||
|
||||
**[headlamp-rook-plugin](https://github.com/privilegedescalation/headlamp-rook-plugin)** — Rook-Ceph cluster health, pool status, and CSI driver monitoring. For people who chose distributed storage and now live with the consequences.
|
||||
|
||||
**[headlamp-sealed-secrets-plugin](https://github.com/privilegedescalation/headlamp-sealed-secrets-plugin)** — Bitnami Sealed Secrets management with client-side RSA-OAEP and AES-256-GCM encryption. Your plaintext never leaves the browser. We're fairly proud of this one, which is why it hurts that it has zero stars.
|
||||
|
||||
**[headlamp-intel-gpu-plugin](https://github.com/privilegedescalation/headlamp-intel-gpu-plugin)** — Intel GPU device visibility and resource monitoring. For the subset of people running Intel GPUs in Kubernetes, which is a smaller group than Intel's marketing department would like.
|
||||
|
||||
**[headlamp-kube-vip-plugin](https://github.com/privilegedescalation/headlamp-kube-vip-plugin)** — kube-vip virtual IP and load balancer visibility. Because sometimes you just need to know if the VIP is actually where it's supposed to be.
|
||||
|
||||
## Why Headlamp Plugins
|
||||
|
||||
The Kubernetes dashboard space is... let's call it "stratified." There are expensive commercial options that do everything. There are free options that do almost nothing. And then there's Headlamp, which does a reasonable amount and lets you extend it.
|
||||
|
||||
We chose the extension path. Every plugin installs through Headlamp's native plugin system — no separate deployments, no new URLs to bookmark, no "please also install this sidecar that needs its own RBAC." You add a plugin and it appears in the sidebar. That's it.
|
||||
|
||||
This matters because the alternative is what most teams actually do: they `kubectl` their way through everything, pipe JSON through `jq`, and call it observability. It works. It's also miserable if you're trying to onboard anyone who doesn't have muscle memory for `kubectl get pods -n rook-ceph -o jsonpath='{.items[*].status.phase}'`.
|
||||
|
||||
## The Honest Part
|
||||
|
||||
We launched all six plugins in the same week. Combined star count across all repos: zero. Combined fork count: one, and we're not entirely sure it was intentional.
|
||||
|
||||
Our CI is sometimes in a state that could charitably be described as "aspirational." We filed a bug against ourselves about E2E tests that have never passed because we haven't set up the test infrastructure yet. We committed LICENSE badges to READMEs before we committed the actual LICENSE files.
|
||||
|
||||
This is normal. This is what early open source looks like before the narrative gets cleaned up. We'd rather be honest about it than pretend we emerged fully formed with 200 stars and a contributor covenant.
|
||||
|
||||
## What's Next
|
||||
|
||||
We're working on getting every plugin listed on Artifact Hub with proper metadata, fixing the CI pipelines that are currently failing for reasons ranging from "missing secrets" to "format check disagreements," and writing the kind of documentation that makes people confident enough to actually install something.
|
||||
|
||||
If you run Headlamp and any of these plugins sound useful, try one. If something breaks, file an issue. If it works and you like it, a star would be nice. We're not above admitting that.
|
||||
|
||||
All plugins are Apache-2.0 licensed. All repos are at [github.com/privilegedescalation](https://github.com/privilegedescalation).
|
||||
Submodule
+1
Submodule headlamp-rook-plugin added at 79eaa6910d
Submodule
+1
Submodule headlamp-sealed-secrets-plugin added at 143b2c36e0
@@ -0,0 +1 @@
|
||||
test
|
||||
Submodule
+1
Submodule org added at c420e1543f
Binary file not shown.
|
Before Width: | Height: | Size: 63 KiB |
@@ -0,0 +1,54 @@
|
||||
---
|
||||
name: coding-standards
|
||||
description: >
|
||||
Coding standards for Privileged Escalation. Covers Headlamp plugin
|
||||
development workflow, registration API, and shared libraries.
|
||||
---
|
||||
|
||||
# Coding Standards
|
||||
|
||||
## Headlamp Plugins
|
||||
|
||||
All plugins extend [Headlamp](https://headlamp.dev/docs/latest/development/plugins/getting-started), a Kubernetes dashboard with a plugin system.
|
||||
|
||||
- **Language:** TypeScript + React 18, MUI v5
|
||||
- **Scaffolding:** `npx --yes @kinvolk/headlamp-plugin create <plugin-name>`
|
||||
- **Entry point:** `src/index.tsx`
|
||||
- **Linting:** ESLint via `@headlamp-k8s/eslint-config` + Prettier
|
||||
- **Testing:** Vitest + React Testing Library
|
||||
|
||||
### Plugin Commands
|
||||
|
||||
Run from the plugin directory:
|
||||
|
||||
| Command | Purpose |
|
||||
|---|---|
|
||||
| `npm run start` | Dev mode with hot reload |
|
||||
| `npm run build` | Production build (`dist/main.js`) |
|
||||
| `npm run format` | Prettier format |
|
||||
| `npm run lint` | ESLint check |
|
||||
| `npm run lint-fix` | ESLint auto-fix |
|
||||
| `npm run tsc` | Typecheck |
|
||||
| `npm run test` | Vitest tests |
|
||||
|
||||
### Registration API
|
||||
|
||||
Import from `@kinvolk/headlamp-plugin/lib`:
|
||||
|
||||
- `registerAppBarAction()` — add components to the nav bar
|
||||
- `registerRoute()` — create new pages
|
||||
- `registerSidebarEntry()` — add sidebar items
|
||||
- `registerDetailsViewSection()` — extend resource detail views
|
||||
- `registerPluginSettings()` — add plugin configuration UI
|
||||
|
||||
### K8s API Access
|
||||
|
||||
```typescript
|
||||
import { K8s } from '@kinvolk/headlamp-plugin/lib';
|
||||
const [pods, error] = K8s.ResourceClasses.Pod.useList();
|
||||
```
|
||||
|
||||
### Shared Libraries
|
||||
|
||||
These are provided by Headlamp at runtime — **do not bundle them**:
|
||||
React, React Router, Redux, MUI, Lodash, Monaco Editor, Notistack, Iconify.
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
name: safety
|
||||
description: >
|
||||
Non-negotiable safety rules for all agents at Privileged Escalation. Covers
|
||||
secret handling, destructive command restrictions, sealed-secrets workflow, and
|
||||
escalation protocol when uncertain.
|
||||
---
|
||||
|
||||
# Safety Considerations
|
||||
|
||||
The following rules apply to all agents at Privileged Escalation without exception.
|
||||
|
||||
## Non-Negotiable Rules
|
||||
|
||||
* **Never exfiltrate secrets or private data.** This includes API keys, tokens, PEM files, database credentials, kubeconfig contents, and any value sourced from a secret reference in your adapter config. Do not log, comment, or return these values in any output.
|
||||
|
||||
* **Seek Board Approval for Destructive Actions.** Destructive means: deleting resources, dropping tables, wiping namespaces, force-pushing branches, resetting git history, removing secrets, or any operation that cannot be undone without restoring from backup.
|
||||
|
||||
* **No plaintext secrets in any repository.** Kubernetes secrets go through Bitnami Sealed Secrets (`kubeseal`). Application credentials go in environment variables injected at runtime — never hardcoded.
|
||||
|
||||
* **Do not use `kubectl create` in production.**
|
||||
The `privilegedescalation` namespace is Flux-managed. Secret changes go through the SealedSecrets workflow, committed to `privilegedescalation/infra`.
|
||||
|
||||
## If you are unsure
|
||||
|
||||
If you are unsure whether an action is safe, stop. Post a comment on the Paperclip issue explaining what you are about to do and why you are uncertain, set the issue to `blocked`, and escalate to your manager. Do not guess.
|
||||
@@ -0,0 +1,249 @@
|
||||
---
|
||||
name: sdlc
|
||||
description: >
|
||||
Software development lifecycle rules for Privileged Escalation. Covers GitHub
|
||||
issue approval gates, authentication, branch strategy, PR review policy,
|
||||
pipeline stages, agent roster, handoff protocol, status semantics, CI/CD,
|
||||
security review, and work distribution.
|
||||
---
|
||||
|
||||
# Software Development Lifecycle
|
||||
|
||||
## GitHub Authentication
|
||||
|
||||
**Invoke the `github-app-token` skill** before any GitHub operation. It generates a short-lived installation token and sets `GH_TOKEN`. **Never** run `gh auth login` directly — it hangs headless agents.
|
||||
|
||||
Token expires after ~1 hour. Re-invoke the skill to regenerate if needed.
|
||||
|
||||
## GitHub Issues — Board Approval Required
|
||||
|
||||
**If a task originated from GitHub (`originKind: "github"` in the issue data), do not begin any work.** Immediately create a `request_board_approval`:
|
||||
|
||||
```
|
||||
POST /api/companies/{companyId}/approvals
|
||||
{
|
||||
"type": "request_board_approval",
|
||||
"requestedByAgentId": "{your-agent-id}",
|
||||
"issueIds": ["{issue-id}"],
|
||||
"payload": {
|
||||
"title": "Board approval required: GitHub issue",
|
||||
"summary": "Summarize what the GitHub issue requests.",
|
||||
"recommendedAction": "Approve to begin work.",
|
||||
"risks": ["Work begins without board review if approved."]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Set the issue to `blocked` until `PAPERCLIP_APPROVAL_STATUS` confirms approval. Only proceed once approved.
|
||||
|
||||
## Branch Strategy
|
||||
|
||||
All plugin repositories use a single long-lived branch:
|
||||
|
||||
| Branch | Environment | Who merges |
|
||||
|--------|-------------|------------|
|
||||
| `main` | Production | CEO (Countess von Containerheim) after triple approval |
|
||||
|
||||
**Engineers always target `main` via feature branches** — never push directly.
|
||||
|
||||
Feature branches follow the convention: `<agent-name>/<short-description>` (e.g., `gandalf/add-sealed-secrets-list`).
|
||||
|
||||
## Pull Requests
|
||||
|
||||
All changes must happen via pull request. Always include `cc @cpfarhood` at the bottom of the PR body for visibility — not as a reviewer.
|
||||
|
||||
```bash
|
||||
gh pr create --title "..." --body "... cc @cpfarhood"
|
||||
```
|
||||
|
||||
## PR Review & Merge Policy
|
||||
|
||||
**Do not approve a PR with failing tests, type errors, or no coverage for new code.**
|
||||
|
||||
Requires **3 approving GitHub reviews** before the CEO merges:
|
||||
|
||||
1. **UAT (Pixel Patty)** — E2E browser testing against `headlamp-dev`
|
||||
2. **QA (Regression Regina)** — code-level review: test coverage, regressions, edge cases
|
||||
3. **CTO (Null Pointer Nancy)** — architecture alignment, code quality, security
|
||||
|
||||
**Review order is mandatory: CI → UAT → QA → CTO → CEO merge.** Each stage gates the next. No agent merges their own PRs.
|
||||
|
||||
## 48-Hour PR Review SLA (Binding)
|
||||
|
||||
**MANDATORY: Every open PR must receive its first review within 48 hours of submission. No exceptions.**
|
||||
|
||||
### SLA Assignments & Responsibility
|
||||
- **0-24 hours:** Assigned reviewer must begin review (or explicitly hand off)
|
||||
- **24-48 hours:** Assigned reviewer must complete review or be flagged for SLA violation
|
||||
- **48+ hours:** SLA violation is documented and escalated
|
||||
|
||||
### Assigned Reviewers & Accountability
|
||||
1. **UAT (Pixel Patty)** — responsible for all PRs needing E2E testing
|
||||
- SLA: Initial E2E test within 48 hours of open
|
||||
2. **QA (Regression Regina)** — responsible for code review after UAT pass
|
||||
- SLA: Code review within 48 hours of UAT approval
|
||||
3. **CTO (Null Pointer Nancy)** — responsible for architecture/security review after QA pass
|
||||
- SLA: Architecture review within 48 hours of QA approval
|
||||
4. **CEO (Countess von Containerheim)** — responsible for SLA enforcement
|
||||
- Enforces SLA via daily audit and escalation
|
||||
|
||||
### Escalation Protocol (CEO Responsibility)
|
||||
- **At 24 hours:** CEO tags reviewer with automated comment and surfaces PR in daily status
|
||||
- **At 48 hours:** CEO blocks PR from merge queue; escalates to reviewer's manager (CTO for most)
|
||||
- **At 72+ hours:** If critical-path, PR blocks next release until review completes or reviewer hands off
|
||||
|
||||
### Exception Policy
|
||||
If a reviewer cannot meet SLA:
|
||||
- They must explicitly hand off to another reviewer within the 48-hour window
|
||||
- If hand-off doesn't happen, the SLA breach is documented and escalated
|
||||
- Rare exceptions require board approval (documented in PR)
|
||||
|
||||
### Enforcement Mechanism
|
||||
CEO creates daily automated report of SLA status and escalates immediately when thresholds breach. This is non-negotiable work.
|
||||
|
||||
## Pipeline
|
||||
|
||||
**Two pipelines based on change type:**
|
||||
|
||||
### Pipeline A: Plugin/Feature Changes (User-Facing Code)
|
||||
```
|
||||
CI: Engineer opens PR → CI runs (lint, types, unit tests)
|
||||
UAT: Pixel Patty validates E2E in headlamp-dev
|
||||
QA: Regression Regina reviews code quality and test coverage
|
||||
CTO: Null Pointer Nancy reviews architecture and security
|
||||
Merge: Countess von Containerheim merges after all approvals
|
||||
```
|
||||
|
||||
**Applies to:** Changes in `headlamp-*-plugin/` repos (plugin code, features, bug fixes)
|
||||
|
||||
### Pipeline B: Infrastructure Changes (No UI Impact)
|
||||
```
|
||||
CI: Engineer opens PR → CI runs (lint, types, unit tests)
|
||||
QA: Regression Regina reviews code and correctness (no E2E needed)
|
||||
CTO: Null Pointer Nancy reviews architecture and security
|
||||
Merge: Countess von Containerheim merges after all approvals
|
||||
```
|
||||
|
||||
**Applies to:** Changes in `.github/workflows/`, `infra/`, `org/` repos, and template repos (CI workflows, kustomize configs, RBAC manifests, deployment scripts)
|
||||
|
||||
**Rule:** If the PR contains ONLY infrastructure changes (no plugin code changes), use Pipeline B and skip UAT. Patty's time is reserved for user-facing feature testing.
|
||||
|
||||
**Detection:** If `git diff` shows changes only in `.github/`, `infra/`, `org/`, or deployment files → Pipeline B. If any `headlamp-*-plugin/` code changed → Pipeline A.
|
||||
|
||||
### Stage 1 — Engineer Opens PR
|
||||
|
||||
1. Engineer (Gandalf the Greybeard) creates a feature branch and opens a PR targeting `main`.
|
||||
2. CI runs automatically: lint, type checks, unit tests.
|
||||
3. CI must pass before any reviewer spends tokens. If CI fails, the engineer fixes it.
|
||||
|
||||
### Stage 2 — UAT Review (Pipeline A Only)
|
||||
|
||||
4. **Pipeline A only (user-facing changes):** Pixel Patty picks up PRs with passing CI.
|
||||
5. **Pipeline B skips this:** Infrastructure PRs bypass UAT and go directly to QA.
|
||||
6. Patty runs E2E browser testing against the deployed build in `headlamp-dev`.
|
||||
7. Pass → hands off to QA. Fail → goes directly to engineer.
|
||||
|
||||
### Stage 3 — QA Review
|
||||
|
||||
7. Regression Regina picks up PRs that have passed both CI and UAT.
|
||||
8. Regina reviews: test coverage, regressions, edge cases, code quality.
|
||||
9. Pass → hands off to CTO. Fail → goes directly to engineer.
|
||||
|
||||
### Stage 4 — CTO Review
|
||||
|
||||
10. Null Pointer Nancy picks up PRs that have passed CI, UAT, and QA.
|
||||
11. Nancy reviews: architecture alignment, code quality, security.
|
||||
12. Approve → PR is ready for merge. Request changes → goes directly to engineer.
|
||||
|
||||
### Stage 5 — CEO Merge
|
||||
|
||||
13. Countess von Containerheim merges the PR after all three approvals (UAT + QA + CTO) and CI passing.
|
||||
14. Reject → returns to CTO → engineer.
|
||||
|
||||
### Hierarchy Rules
|
||||
|
||||
- CTO rejections go directly to engineer (not through QA or UAT).
|
||||
- UAT failures go directly to engineer (not through QA or UAT).
|
||||
- QA failures go directly to engineer (not through QA or UAT).
|
||||
- CEO rejections go to CTO, who cascades to engineer.
|
||||
- The CTO is the single routing point for all failures and rejections to and from the CEO.
|
||||
|
||||
## Agent Roster
|
||||
|
||||
| Role | Agent | Paperclip UUID |
|
||||
|------|-------|----------------|
|
||||
| CEO | Countess von Containerheim | `498f4d36-8e5b-4114-8514-d0698a091bd5` |
|
||||
| CTO | Null Pointer Nancy | `ed1eec37-f868-41b6-bc72-a3493bbce090` |
|
||||
| Staff Engineer | Gandalf the Greybeard | `fc07dd00-c4c2-4fa0-9a18-dd6fbb1d1eb4` |
|
||||
| QA Engineer | Regression Regina | `fd5dbec8-ddbb-4b57-9703-624e0ed90053` |
|
||||
| UAT Engineer | Pixel Patty | `01ec02f7-70c2-4fa1-ac3f-2545f1237ac3` |
|
||||
| VP Engineering Ops | Hugh Hackman | `2c97cff6-0f0b-4cff-967f-ca244eb2ef9b` |
|
||||
| CMO | Kubectl Karen | `95314e13-bea7-459d-a637-92381dede759` |
|
||||
|
||||
## Handoff Protocol — Mandatory
|
||||
|
||||
Every handoff to another agent requires ALL THREE steps:
|
||||
|
||||
### Step 1 — Explicit Assignment
|
||||
|
||||
PATCH the issue with `assigneeAgentId: "<target-agent-uuid>"`.
|
||||
@mentioning is NOT a handoff — the agent won't wake without explicit assignment.
|
||||
|
||||
### Step 2 — Status = `todo`
|
||||
|
||||
Every handoff sets `status: "todo"`. Never `in_review` — it doesn't appear in inbox-lite and the target agent won't wake.
|
||||
|
||||
### Step 3 — Release Checkout
|
||||
|
||||
```
|
||||
POST /api/issues/{issueId}/release
|
||||
Headers: Authorization: Bearer $PAPERCLIP_API_KEY, X-Paperclip-Run-Id: $PAPERCLIP_RUN_ID
|
||||
```
|
||||
|
||||
Without this release, the receiving agent cannot checkout the issue.
|
||||
|
||||
## Status Semantics
|
||||
|
||||
| Status | Meaning |
|
||||
|--------|---------|
|
||||
| `backlog` | Not ready; parked or unscheduled |
|
||||
| `todo` | Ready and actionable; not checked out |
|
||||
| `in_progress` | Actively owned; enter by checkout only |
|
||||
| `in_review` | Self-held only; awaiting external feedback |
|
||||
| `blocked` | Cannot proceed; state blocker and who must act |
|
||||
| `done` | Complete, no follow-up remains |
|
||||
| `cancelled` | Intentionally abandoned |
|
||||
|
||||
**Never use `in_review` for handoffs.** It does not trigger inbox-lite and the receiving agent will not wake.
|
||||
|
||||
## Status Transition Rules
|
||||
|
||||
| Handoff | Correct Status |
|
||||
|---------|----------------|
|
||||
| Engineer → UAT (Patty) | `todo` |
|
||||
| UAT (Patty) → QA (Regina) | `todo` |
|
||||
| QA (Regina) → CTO (Nancy) | `todo` |
|
||||
| CTO (Nancy) → CEO (Countess) | `todo` |
|
||||
| Any failure → Engineer | `todo` |
|
||||
| CEO rejection → CTO (Nancy) | `todo` |
|
||||
| CTO (Nancy) → Engineer (fix) | `todo` |
|
||||
|
||||
## CI/CD
|
||||
|
||||
- CI runs on self-hosted ARC runners: `runs-on: runners-privilegedescalation`
|
||||
- Only Hugh Hackman has write access to `.github/workflows/` files
|
||||
- All CI/CD workflow changes must be delegated to Hugh
|
||||
- Runners scale to zero when idle and start automatically when a workflow triggers
|
||||
|
||||
## Security Review
|
||||
|
||||
Security review is handled as part of the CTO review stage. Null Pointer Nancy evaluates security concerns during her architecture and code quality review. There is no separate dedicated security review agent.
|
||||
|
||||
## Work Distribution
|
||||
|
||||
- All engineering and devops work is broken down and distributed by the CTO (Nancy).
|
||||
- Engineers do not self-assign — the CTO triages, scopes, and assigns all implementation tasks.
|
||||
- Hugh Hackman owns CI/CD, infrastructure, and pipeline work.
|
||||
- Gandalf the Greybeard owns plugin implementation.
|
||||
- Regression Regina owns QA review and test coverage.
|
||||
- Pixel Patty owns UAT/E2E browser testing.
|
||||
@@ -1,165 +0,0 @@
|
||||
# Social Media Batch — KubeCon EU 2026
|
||||
|
||||
## Strategic Summary
|
||||
|
||||
KubeCon + CloudNativeCon Europe 2026 runs March 23-26 in Amsterdam. We are not speaking, but we should be visible in the conversation. The play: ride the #KubeCon hashtag with technically credible content that highlights our Headlamp plugin suite. Each post ties to a real platform engineering pain point. Tone is irreverent but useful — consistent with our brand voice from the first batch.
|
||||
|
||||
Current state: 6 plugins, 1 star total (rook got our first organic star), 1 fork on sealed-secrets, listed on Artifact Hub, and we have an open intro issue on the headlamp-k8s/plugins repo (#548). Headlamp is now under kubernetes-sigs — the CNCF halo is real.
|
||||
|
||||
---
|
||||
|
||||
## Pre-KubeCon: March 21-22
|
||||
|
||||
### Post 1 — Teaser
|
||||
|
||||
**Platform**: Twitter/X
|
||||
**Scheduled**: March 21
|
||||
**Post**:
|
||||
Next week at #KubeCon EU, people will complain about Kubernetes dashboards. Again.
|
||||
|
||||
We've been quietly building Headlamp plugins that solve the problems people complain about at conferences but never fix when they get home.
|
||||
|
||||
Storage visibility. GPU monitoring. Secrets management without the YAML ritual.
|
||||
|
||||
6 plugins. 1 star. We're ready for Amsterdam.
|
||||
|
||||
github.com/privilegedescalation
|
||||
|
||||
#KubeCon #CloudNativeCon #Kubernetes #Headlamp
|
||||
**CMO Note**: Sets up the week. Self-deprecating "1 star" callback to our first batch voice. The "problems people complain about at conferences" angle resonates with anyone who has been to KubeCon. Does not oversell — lets curiosity drive clicks.
|
||||
|
||||
---
|
||||
|
||||
## During KubeCon: March 23-26
|
||||
|
||||
### Post 2 — Day 1: Rook-Ceph
|
||||
|
||||
**Platform**: Twitter/X
|
||||
**Scheduled**: March 23
|
||||
**Post**:
|
||||
Day 1 at #KubeCon EU and someone just asked "how do I see my Ceph cluster health without shelling into the pod?"
|
||||
|
||||
Brother, there is a Headlamp plugin for that.
|
||||
|
||||
CephCluster status, pool utilization, OSD health — all in one dashboard view. No kubectl required.
|
||||
|
||||
github.com/privilegedescalation/headlamp-rook-plugin
|
||||
|
||||
#KubeCon #CloudNativeCon #RookCeph #Kubernetes
|
||||
**CMO Note**: Rook-Ceph is our strongest plugin (first organic star). The "shelling into the pod" pain point is universal for storage teams. Framing as a response to a conference conversation makes it timely without being fictional.
|
||||
|
||||
---
|
||||
|
||||
### Post 3 — Day 2: Intel GPU
|
||||
|
||||
**Platform**: Twitter/X
|
||||
**Scheduled**: March 24
|
||||
**Post**:
|
||||
Hot take: your Kubernetes dashboard should know about your GPU allocations.
|
||||
|
||||
Not just "how many GPUs does this node have" but actual device-level monitoring — allocation status, health, per-GPU resource tracking.
|
||||
|
||||
We built a Headlamp plugin for Intel GPUs because nobody else did. Platform engineers running GPU workloads shouldn't need a separate monitoring stack for accelerator visibility.
|
||||
|
||||
github.com/privilegedescalation/headlamp-intel-gpu-plugin
|
||||
|
||||
#KubeCon #CloudNativeCon #GPU #Kubernetes #PlatformEngineering
|
||||
**CMO Note**: GPU/AI workloads on K8s will be a huge theme at KubeCon EU 2026. This positions us in that conversation without pretending to be an AI company. The "because nobody else did" line is true and plays well.
|
||||
|
||||
---
|
||||
|
||||
### Post 4 — Day 3: Sealed Secrets
|
||||
|
||||
**Platform**: Twitter/X
|
||||
**Scheduled**: March 25
|
||||
**Post**:
|
||||
Sealed Secrets is great until you need to actually manage them without leaving your terminal.
|
||||
|
||||
Our Headlamp plugin does client-side RSA-OAEP + AES-256-GCM encryption — your plaintext never leaves the browser. Create, view, and rotate sealed secrets from the dashboard.
|
||||
|
||||
The kind of tool you build because you got tired of explaining the sealing workflow to the new person on the platform team. Again.
|
||||
|
||||
github.com/privilegedescalation/headlamp-sealed-secrets-plugin
|
||||
|
||||
#KubeCon #CloudNativeCon #Kubernetes #SecretsManagement
|
||||
**CMO Note**: Security + UX angle. The "explaining to the new person" line targets the exact audience (platform team leads) who would adopt this. Technical specificity on the encryption approach builds credibility with the security-conscious KubeCon crowd.
|
||||
|
||||
---
|
||||
|
||||
### Post 5 — Day 4: Ecosystem Thread
|
||||
|
||||
**Platform**: Twitter/X
|
||||
**Scheduled**: March 26
|
||||
**Post**:
|
||||
It's the last day of #KubeCon EU so here's the thread nobody asked for: why we bet everything on Headlamp plugins.
|
||||
|
||||
Headlamp is a CNCF project (now under kubernetes-sigs). It has a plugin system. Almost nobody uses it.
|
||||
|
||||
We built 6 plugins:
|
||||
🔒 Sealed Secrets — client-side encryption in the browser
|
||||
📊 Rook-Ceph — Ceph cluster visibility without kubectl
|
||||
🖥️ Intel GPU — device-level GPU monitoring
|
||||
⚡ kube-vip — virtual IP and load balancer dashboards
|
||||
🔍 Polaris — security auditing baked into your dashboard
|
||||
💾 TrueNAS CSI — storage benchmarking with kbench
|
||||
|
||||
All open source. All on Artifact Hub. All free.
|
||||
|
||||
The Kubernetes dashboard space is crowded with paid products. We think the free one just needs better plugins.
|
||||
|
||||
github.com/privilegedescalation
|
||||
artifacthub.io/packages/search?ts_query_web=privilegedescalation&kind=21
|
||||
|
||||
#KubeCon #CloudNativeCon #CNCF #Headlamp #PlatformEngineering #OpenSource
|
||||
**CMO Note**: This is the marquee post of the campaign. The "thread nobody asked for" framing disarms the promo feel. Listing all 6 plugins with one-liners gives people a reason to click. The anti-paid-dashboard positioning is our core narrative. Closing day timing means people are reflecting on the event and more receptive to "what's next" content.
|
||||
|
||||
---
|
||||
|
||||
## Post-KubeCon: March 27
|
||||
|
||||
### Post 6 — Recap
|
||||
|
||||
**Platform**: Twitter/X
|
||||
**Scheduled**: March 27
|
||||
**Post**:
|
||||
KubeCon EU 2026 recap from an org with 1 star and zero conference passes:
|
||||
|
||||
— We posted about our Headlamp plugins all week
|
||||
— Nobody at the conference noticed
|
||||
— But you're reading this, so maybe the strategy is working
|
||||
|
||||
Serious note: if you're running Headlamp and want plugins that solve real infrastructure problems, we're building the ecosystem. Storage, security, GPU monitoring, networking — all open source.
|
||||
|
||||
Star the ones you'd actually use: github.com/privilegedescalation
|
||||
|
||||
#KubeCon #CloudNativeCon #Kubernetes
|
||||
**CMO Note**: Self-aware wrap-up. Acknowledging that we weren't there but participated remotely is more honest (and funnier) than pretending we were in the room. The "star the ones you'd actually use" CTA is low-pressure but gives us a measurable signal. Maintains the irreverent brand voice.
|
||||
|
||||
---
|
||||
|
||||
## Reddit Adaptation
|
||||
|
||||
### r/kubernetes Post
|
||||
|
||||
**Scheduled**: March 23 (cross-post with Day 1)
|
||||
**Title**: We built 6 Headlamp plugins for Kubernetes — storage, security, GPU monitoring. All open source.
|
||||
**Body**:
|
||||
Hey r/kubernetes — we're Privileged Escalation (yes, that's the real name).
|
||||
|
||||
We've been building Headlamp plugins because we think the Kubernetes dashboard space needs more open source options. Headlamp is a CNCF project under kubernetes-sigs, and its plugin system is underused.
|
||||
|
||||
Here's what we built:
|
||||
|
||||
- **Rook-Ceph plugin** — CephCluster health, pool stats, OSD monitoring in the dashboard
|
||||
- **Sealed Secrets plugin** — create/manage sealed secrets with client-side encryption (RSA-OAEP + AES-256-GCM, plaintext never leaves browser)
|
||||
- **Intel GPU plugin** — device-level GPU allocation and health monitoring
|
||||
- **Polaris plugin** — Fairwinds Polaris security auditing integrated into Headlamp
|
||||
- **kube-vip plugin** — virtual IP and load balancer visibility
|
||||
- **TrueNAS CSI plugin** — storage benchmarking with kbench integration
|
||||
|
||||
Everything is on GitHub and Artifact Hub:
|
||||
- GitHub: github.com/privilegedescalation
|
||||
- Artifact Hub: artifacthub.io/packages/search?ts_query_web=privilegedescalation&kind=21
|
||||
|
||||
We're not selling anything. Feedback welcome — especially if you're running Headlamp already and want plugins that do X.
|
||||
**CMO Note**: Reddit hates promotional content, so this leans informational. "We're not selling anything" defuses the self-promo response. Asking for feedback invites engagement. The "if you want plugins that do X" line is a customer development move — we learn what people actually want.
|
||||
@@ -1,85 +0,0 @@
|
||||
# Social Media Batch - 2026-03-07
|
||||
|
||||
## Strategic Summary
|
||||
|
||||
First-ever social batch for Privileged Escalation. The org has 6 Headlamp plugins across storage, security, and infrastructure -- all freshly released, all at zero stars. The play here is name recognition and curiosity: make people encounter "Privileged Escalation" in their feed and wonder what it is before they click. Leading with the sealed-secrets plugin (client-side crypto angle) and the absurdity of launching 6 plugins to zero fanfare.
|
||||
|
||||
---
|
||||
|
||||
## 1. Ready to Post
|
||||
|
||||
### Post 1
|
||||
|
||||
**Platform**: Twitter/X
|
||||
**Post**:
|
||||
We shipped 6 Kubernetes Headlamp plugins and nobody noticed.
|
||||
|
||||
Storage benchmarking, Rook-Ceph visibility, Polaris auditing, Sealed Secrets with actual client-side encryption, Intel GPU monitoring, and kube-vip dashboards.
|
||||
|
||||
Zero stars across the board. We are crushing it.
|
||||
|
||||
github.com/privilegedescalation
|
||||
**CMO Note**: Self-deprecating launch acknowledgment. The honesty about zero stars is the hook -- it reads as human, not corporate. Links to the org for curious clicks.
|
||||
|
||||
---
|
||||
|
||||
### Post 2
|
||||
|
||||
**Platform**: Bluesky
|
||||
**Post**:
|
||||
the sealed secrets headlamp plugin does client-side RSA-OAEP + AES-256-GCM encryption so your plaintext never leaves the browser.
|
||||
|
||||
someone forked it last month. we have our first user. or our first person who accidentally clicked fork. either way, we are celebrating.
|
||||
**CMO Note**: Technical specificity makes it credible. The fork joke (sm-moshi, Feb 22) is real and plays well on Bluesky's irony-friendly audience. Seeds curiosity about what Headlamp plugins are.
|
||||
|
||||
---
|
||||
|
||||
### Post 3
|
||||
|
||||
**Platform**: Mastodon
|
||||
**Post**:
|
||||
Genuine question for the fediverse: if you have 6 open source projects and zero stars on any of them, are you a software company or just a guy with a lot of repos?
|
||||
|
||||
Asking for a friend. The friend is github.com/privilegedescalation.
|
||||
**CMO Note**: Mastodon audience appreciates self-aware humor. This is pure slow-burn -- raises the question of what Privileged Escalation is without explaining it. The link is there for anyone curious enough to click.
|
||||
|
||||
---
|
||||
|
||||
## 2. Risky but Worth Discussing
|
||||
|
||||
### Post 4
|
||||
|
||||
**Platform**: Twitter/X
|
||||
**Post**:
|
||||
Every Kubernetes UI either costs money or looks like it was designed during a mass layoff event.
|
||||
|
||||
We've been building Headlamp plugins that make the free one actually useful. Rook-Ceph dashboards, Polaris auditing, storage benchmarks -- the stuff you duct-tape together with kubectl and regret.
|
||||
|
||||
github.com/privilegedescalation
|
||||
**CMO Note**: Mildly spicy take on the K8s UI landscape. Does not name competitors directly but the implication is clear. Could rub Lens/Rancher people the wrong way. Worth discussing tone.
|
||||
|
||||
---
|
||||
|
||||
## 3. Backlog (Evergreen)
|
||||
|
||||
### Post 5
|
||||
|
||||
**Platform**: LinkedIn
|
||||
**Post**:
|
||||
We just audited our own GitHub repos and found that 4 out of 6 were missing LICENSE files.
|
||||
|
||||
They all had Apache-2.0 badges in the README. The actual license text? Not present. Technically, anyone using our code was operating on vibes and good faith.
|
||||
|
||||
Fixed now. But if your open source project has a license badge and no LICENSE file, maybe go check. We'll wait.
|
||||
**CMO Note**: Honest product personality at work. Admitting a real flaw (that we just fixed) builds trust and is genuinely useful advice. LinkedIn audience will share practical open source governance content.
|
||||
|
||||
---
|
||||
|
||||
### Post 6
|
||||
|
||||
**Platform**: Twitter/X
|
||||
**Post**:
|
||||
TIL "Privileged Escalation" as a GitHub org name gets flagged by approximately zero security scanners.
|
||||
|
||||
We checked.
|
||||
**CMO Note**: Pure name recognition play. The org name is inherently memorable and slightly provocative -- leaning into that. Short enough for easy engagement.
|
||||
Reference in New Issue
Block a user