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

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

   kubectl apply -f oxidized-prod3.yaml
   

2. 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>.)

3. Verify:

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