Creating a NS for a user

Willard is working on building a system to easily create namespaces for users. Until then, they have to do it manually. Here's how:

Create the resources

```

apiVersion: v1
kind: Namespace
metadata:
  name: oxidized
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: oxidized-admin
  namespace: oxidized
rules:
- apiGroups:
  - ""
  - extensions
  - apps
  resources:
  - '*'
  verbs:
  - '*'
- apiGroups:
  - batch
  resources:
  - jobs
  - cronjobs
  verbs:
  - '*'
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: oxidized
  namespace: oxidized
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: oxidized-admin-binding
  namespace: oxidized
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: oxidized-admin
subjects:
- kind: ServiceAccount
  name: oxidized
  namespace: oxidized ```

Apply this manifest on the cluster, or better yet, do it in a Helm chart.

RBAC scope

The oxidized-admin Role grants * verbs on:

all resources in apiGroups "" (core), extensions, apps jobs, cronjobs in apiGroup batch

Not covered (deliberately, mirroring the dev3 inventory-admin role): networking.k8s.io, rbac.authorization.k8s.io, policy, autoscaling, storage.k8s.io, admissionregistration.k8s.io, etc. Outside the oxidized namespace the account has no permissions at all.

```Caveat: since core-group resources are fully open, the account can create tokens for any service account inside oxidized (the serviceaccounts/token subresource). Fine for a trusted workload, worth knowing.

Token lifetime

Tokens minted like this expire every 90 days (issued with --duration=2160h).

To refresh it before it expires:

# with an admin kubeconfig for prod3 (e.g. the prod3 alias in ~/.zshrc)
TOKEN=$(prod3 create token oxidized -n oxidized --duration=2160h)

# replace the token line in the kubeconfig
sed -i.bak "s|^    token: .*|    token: $TOKEN|" \
  ~/Documents/oxidized-k8s/oxidized-prod3-kubeconfig.yaml

# verify
KUBECONFIG=~/Documents/oxidized-k8s/oxidized-prod3-kubeconfig.yaml kubectl auth whoami

Note: stock k8s caps create token durations at 24h; this k3s instance accepts 2160h. If that stops working, the fallback is a legacy token secret (type: kubernetes.io/service-account-token), which is valid indefinitely.

Reproducing on a new cluster

Apply the full manifest set (adjust nothing — all names are generic):

kubectl apply -f oxidized-prod3.yaml

Issue a token and build a kubeconfig:

TOKEN=$(kubectl create token oxidized -n oxidized --duration=2160h)
CA=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.certificate-authority-data}')
SERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')

cat > oxidized-kubeconfig.yaml <<EOF
apiVersion: v1
kind: Config
clusters:
- cluster:
    server: $SERVER
    certificate-authority-data: $CA
  name: oxidized
users:
- name: oxidized
  user:
    token: $TOKEN
contexts:
- context:
    cluster: oxidized
    user: oxidized
    namespace: oxidized
  name: oxidized
current-context: oxidized
EOF

(Recent kubectl versions redact data fields in config view output — if certificate-authority-data comes back empty, read it from the raw kubeconfig file instead: awk '/certificate-authority-data:/{print $2}' ~/.kube/<config>.)

Verify:

KUBECONFIG=oxidized-kubeconfig.yaml kubectl auth whoami
KUBECONFIG=oxidized-kubeconfig.yaml kubectl auth can-i '*' '*' -n oxidized