[WIP] Implement --access-key flag and serverless keys commands #1783
Conversation
vrindavinod-do
changed the title
logwolvy
left a comment
logwolvy
left a comment
There was a problem hiding this comment.
Is that all for the access key new arch to work?
Also, any way to test this?
I've implemented [doctl serverless connect --access-key] which stores the credentials. All other serverless commands (deploy, functions, etc.) automatically use the stored credentials. Is this the intended scope, or do you need direct auth-key support on every individual serverless command? like: doctl serverless deploy --access-key "uuid:key" ./my-function? To test, I see that can make doctl point to stage2 or your local address |
vrindavinod-do
changed the title
logwolvy
left a comment
logwolvy
left a comment
There was a problem hiding this comment.
Will there be a separate PR for access key CRUD ops?
DO-rrao
left a comment
DO-rrao
left a comment
There was a problem hiding this comment.
As discussed with @vrindavinod-do , will be reviewing this PR with the access keys changes.
vrindavinod-do
changed the title
- Ran gofmt on all source files - Ensured all tests pass - Code is now properly formatted
- Replaced map[string]interface{} with map[string]any
- Applied Go 1.18+ preferred syntax for interface types
- All tests continue to pass
- Resolves gofmt_check CI failure
logwolvy
left a comment
logwolvy
left a comment
There was a problem hiding this comment.
What will be the behaviour for other commands (deploy, fn list...) after deprecation of legacy keys, if no access keys were added by the user via doctl connect cmd?
if users haven't added access keys via the new [doctl serverless connect --access-key] command, all serverless operations will fail with: |
| `Creates a new access key for the specified namespace. The secret is displayed only once upon creation. | ||
| Examples: | ||
| doctl serverless key create --name "my-laptop-key" --expiration 30d |
There was a problem hiding this comment.
@vrindavinod-do We need to allow custom expiration durations - 1h, 7d
Format should be parsed/validated in portal-aggregator and the following format could be used - <hour|day>
Minimum TTL value can be 1h and this should be validated in portal-aggregator.
| doctl serverless key create --name "ci-cd-key" --namespace fn-abc123 --expiration never`, | ||
| Writer) | ||
| AddStringFlag(create, "name", "n", "", "name for the access key", requiredOpt()) | ||
| AddStringFlag(create, "expiration", "e", "", "expiration period: 30d, 60d, 90d, 1y, or never", requiredOpt()) |
There was a problem hiding this comment.
@vrindavinod-do We need to allow custom expiration durations - 1h, 7d
Format should be parsed/validated in portal-aggregator and the following format could be used -
<integer><hour|day>
Minimum TTL value can be 1h and this should be validated in portal-aggregator.
| // During creation: show the full secret | ||
| secret = key.Secret | ||
| } | ||
| // For all other cases (listing, etc.): always show "<hidden>" |
There was a problem hiding this comment.
For list view, should we even have a column for "secret"?
Adding the auth-key flag implementation:
1. Our access-key implementation
doctl serverless connect my-namespace --access-key "dof_v1_abc123:secretkey"
→ Validates access-key (OpenWhisk)
→ Stores in credentials.json: {"currentHost": "api.host", "currentNamespace": "my-namespace", "credentials": {"api.host": {"my-namespace": {"api_key": "dof_v1_abc123:secretkey"}}}}
2. All other commands automatically work
doctl serverless functions list
→ CheckServerlessStatus() ✅ (finds credentials.json)
→ ReadCredentials() ✅ (gets YOUR access-key)
→ initWhisk() ✅ (creates OpenWhisk client with YOUR access-key)
→ API calls succeed ✅
doctl serverless deploy ./my-function
→ Same credential flow ✅
→ Deploy uses YOUR access-key ✅
New commands:
doctl serverless key create --name "my-key" # Create new access key
doctl serverless key list # List all keys
doctl serverless key revoke