Multi-user credential provisioning for load testing
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 8
- Forks
- 1
- Avg merge
- 18h 23m
- Merged PRs (30d)
- 63
Description
The load and session simulation tests (#119, PR #124) share a single credential across all concurrent requests/sessions. This tests server capacity but not multi-user session isolation, per-user resource limits, or auth middleware under multi-user load.
What's needed
Provision N unique user accounts with per-user credentials so each simulated Locust user authenticates as a different identity.
Credential provisioning by auth type
| Auth Type | Provisioning Path | Feasibility |
|---|---|---|
| Keycloak (PTD) | Bulk create via Keycloak admin API (src/vip/verify/credentials.py already creates single users). Mint per-user Connect API keys, Workbench tokens, PM tokens via kubectl exec. |
Ready to build — infrastructure exists |
| LDAP | Create users via LDAP admin, then mint product credentials | Possible but needs LDAP client |
| SSO (Okta, Azure AD) | Cannot auto-provision — IDP owns user directory | Requires pre-provisioned credentials file |
| Password (local) | Connect: POST /__api__/v1/users. Workbench: rstudio-server add-user. |
Straightforward |
Design
vip load provision --users 50— create N test users + credentialsvip load cleanup— delete all provisioned test users + credentials- Credentials stored in K8s Secret (Keycloak path) or local JSON file
- Locust user classes pick credentials from pool via round-robin
- Configurable pool size via
performance.load_user_pool_sizeinvip.toml - Default: 50 users (at 10K concurrent, ~200 sessions per credential)
Scope
- Bulk Keycloak user creation (extend
ensure_keycloak_test_userto N users) - Per-user Connect API key minting
- Per-user Workbench token generation
- Per-user PM token generation
- Credential pool storage (K8s Secret or JSON file)
- Locust user classes consume credential pool
- Cleanup command
- Credentials file fallback for non-Keycloak deployments
- Documentation
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with src/vip/verify/credentials.py and the load and session simulation tests from #119 and PR #124. Trace how Locust users currently obtain credentials, then map the provisioning, storage, consumption, cleanup, fallback, and documentation checklist items. Done means distinct users can authenticate under each supported path and provisioned credentials can be cleaned up.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kubernetes, python
- Domain
- authentication, devops, performance, testing-qa
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100