Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend token-vendor to aid with cleaning up stale robot registrations #320

Open
ensonic opened this issue Feb 1, 2024 · 0 comments
Open

Comments

@ensonic
Copy link
Contributor

ensonic commented Feb 1, 2024

See #PR/318.

Right now when deleting a registered robot (by deleting the robot-cr), the associated pubkey is not deleted, leading to an accumulation of stale pubkey configmaps in the app-tokenvendor namespace.

Some ideas:

  1. token vendor could watch robot-crs and also delete pubkeys when robots are deleted. I should not auto delete pubkey where we don't have a robot-cr in the cloud as we support a dev-setup, where the robot-cr is not synced to the cloud.
  2. token-vendor could build an in-memory map of last seen timestamps and on a low rate (every 15 min), write those back to the pubkeys. Then one can script against this.
  3. token-vendor could use a counter metric for the verify requests and label them with the robot-id. Not sure if this would cause too high cardinality.

We should also consider to label the pub-keys for easy filtering in the backup_robots.sh script.

ensonic added a commit that referenced this issue Feb 1, 2024
This will let us efficiently filter, e.g. when backing them up. Adjust
the backup script to filter by label.

Existing registrytion can be backfilled by e.g.:
```bash
function kc {
  kubectl --context="${KUBE_CONTEXT}" -n app-token-vendor "$@"
}

for cm in $(kc get cm -o name | egrep "^configmap/robot-"); do
 kc label "$cm" --overwrite app.kubernetes.io/managed-by=token-vendor
done
```

See also: #320
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant