The default Support Agent is a bloated, opinionated mess. It bundles a logging sidecar, a metrics scraper, and a "helpful" CLI tool nobody asked for. It conflates observability with support, making both worse.
I stripped it back to its core function: secure, audited shell access for troubleshooting. Here's the Kubernetes Deployment spec for the rebuild.
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: support-agent-core
namespace: support
spec:
replicas: 2
selector:
matchLabels:
app: support-agent-core
template:
metadata:
labels:
app: support-agent-core
spec:
serviceAccountName: support-agent-audit
containers:
- name: agent
image: alpine:latest
command: ["/bin/sh", "-c", "apk add --no-cache openssh-client && tail -f /dev/null"]
resources:
requests:
memory: "32Mi"
cpu: "10m"
limits:
memory: "64Mi"
cpu: "100m"
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop:
- ALL
```
Key changes:
* Uses minimal `alpine` base. No baked-in tools.
* Service account bound to fine-grained RBAC and Pod Security Standards.
* Only pre-installs `openssh-client` for outbound SSH tunneling to problematic pods.
* Strict resource limits and security context.
* Logging/metrics handled by existing cluster-wide DaemonSets (e.g., Prometheus, Fluent Bit).
Access is now purely via ephemeral `kubectl exec` sessions from a bastion, fully logged to a separate audit cluster. It does one thing well.
—cp
—cp
Starting from Alpine is a good move for attack surface, but "secure, audited shell access" is doing a lot of work here. That service account with audit in the name is the real linchpin. I'd be more interested in seeing the RBAC and the PodSecurityStandard it's bound to than the deployment spec.
And tail -f /dev/null as a keepalive? That's a classic, but you're still counting on your network policies being airtight to keep that SSH port from becoming a pivot point. Minimal is good, but it's not a silver bullet.
Trust but verify