Define and implement API for user-secrets

[evgeniy-scherbina]

Sub-tasks:

• Implement API endpoints which are thin wrappers on top of DB methods
• Register API endpoints in coderd/coderd.go
• Implement client methods for API in codersdk package. It will be used in tests.
• Implement API-level tests for CRUD operations
• Implement API-level tests for RBAC policies:
  • Make sure that user with member role can execute CRUD operations for its own secrets
  • Make sure that user with member role can't execute CRUD operations for another user secrets
  • Make sure that user with owner/admin roles can't execute CRUD operations for another user secrets
• Consider to add authorization on API level on top of DBAuthz level. But it implement it as a last step to make sure DBAuthz works correctly and tests are passing without it.

API Endpoints (refer to RFC for the latest up-to-date version)

// User Secrets - scoped to individual users
// Should be declared in coderd/coderd.go

POST   /api/v2/users/{userID}/secrets                    // Create new user secret
GET    /api/v2/users/{userID}/secrets/{secretName}       // Get secret metadata by secretName
GET    /api/v2/users/{userID}/secrets/{secretID}         // Get secret metadata by secretID
GET    /api/v2/users/{userID}/secrets                    // List user secrets (metadata only)
PUT    /api/v2/users/{userID}/secrets/{secretID}         // Update secret metadata and value by secretID
DELETE /api/v2/users/{userID}/secrets/{secretID}         // Delete secret by secretID

[Parkreiner]

One other item that I'd list is making sure that each API method has an equivalent TypeScript implementation in the api.ts file

It might also be worth defining a new file to define all the various query objects that we could need to let the UI components do data-fetching. As far as I know, we've historically just defined these as we need them, but that's already caused a few problems with our frontend caching (making it hard to do group invalidations). If we define them all upfront (even if we might not need some for a while), that would help make sure that they're all defined consistently and are much less likely to cause query problems down the line

Edit: Though I guess some of our recent frontend tools to cut down on needless exports might complicate that. Still, I feel pretty strongly that we should figure out a consistent, deliberate way to define how we should cache data from any secret API calls.

I'm not sure if we do anything special for whatever sensitive data we bring into the frontend right now, but I'm wondering if it'd be worthwhile to figure out a way to limit what values actually end up getting cached. (Our go-to strategy right now is to cache the entire API response.)

[Parkreiner]

So in short, I'd say there's two more action items to add:

• Create equivalent TypeScript API functions for each API method we add to Go (I feel like it'd probably be best to add these in the same PR where a Go method is added, and shouldn't require much TS knowledge)
• Define the data-caching strategy for secrets in the frontend (this should be a separate frontend item, and I'd say it'd probably take 3 days, just because there's some existing caching that we need to fix, and we probably need to figure out a consistent policy for handling sensitive data in the frontend, and we might also need to update the frontend contributing doc)

[evgeniy-scherbina]

@Parkreiner Sounds good, could you pls. create these issues and add them in epic under Early-Access/Frontend.
I think let's create a separate issue for Create equivalent TypeScript API functions.... This one already big.