Replies: 3 comments 6 replies
-
|
It's not mentioned here, but the addition of a password field type to the In our use case, our users don't use the Otherwise, these changes are definitely a move in the right direction. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the input. I like the idea of |
Beta Was this translation helpful? Give feedback.
-
|
Nice. // devcontainer.json
// [...]
"secrets": {
"JF_TOKEN": {
"description": "Jfrog artifactory token used by the post-start script.",
"documentationUrl": "..."
},
"FOO_API_SECRET": {
"description": "The required api key to target service foo..."
"documentationUrl": "..."
}
} |
Beta Was this translation helpful? Give feedback.
-
|
I will try how this works. As far as I know, this is a GitHub CodeSpaces-specific syntax to recommend a user to set these secrets. |
Beta Was this translation helpful? Give feedback.
-
|
Nice! sources:
usage cliThe devcontainer cli takes an option called --secrets-file which just takes a json file of key value pair: During workspace provision, based on the secret section in // file /path/to/secrets.json
{
"NAME_OF_SECRET_1": "secret-value1",
"NAME_OF_SECRET_2": "secret-value2"
}Then simply adding --secrets-file to the up cmd would be enough to inject secrets into the devcontainer: devcontainer up [...] \
--secrets-file /path/to/secrets.jsonWell it would be a nice UX to validate secrets exists before workspace provision, |
Beta Was this translation helpful? Give feedback.
-
|
@bartekgatzcoder @DanielleMaywood for visibility. Regardless of the method we use to inject secrets, let's strive to support the devcontainer spec. cc: @f0ssel |
Beta Was this translation helpful? Give feedback.
-
|
Storing of secrets should be permitted by administrator on each scope |
Beta Was this translation helpful? Give feedback.
-
|
Related, but administrators should not be able to retrieve the values of user entered secrets. |
Beta Was this translation helpful? Give feedback.
-
|
An organization admin can set organization secrets. I understand that there could be a case where an admin would like to set secrets for headless users (who can not log in). But an admin having access to the token of such a user should be able to set secrets for that user using |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
💥 Problem
Developers often store sensitive information, such as API keys and tokens, insecurely, using plaintext files or chat communications. This practice leads to poor control, lack of visibility, and no audit trail.
Additionally, as noted in Issue #7087, there is a need for a user-level secrets management system. While third-party solutions like HashiCorp Vault and AWS Secrets Manager offer powerful features, they can be complex due to the management of authentication. A native solution in Coder could simplify this process, balancing security and usability.
✅ Solution
Coder will support built-in secrets with 3 scopes:
Secrets can be:
coder secret set)coder secret get🔧 CLI Examples
# List secrets $ coder secret list NAME UPDATED MY_API_KEY 2 days ago VERCEL_TOKEN 10 days ago🖥️ UI Sneak Peek
Secrets will also be configurable via the web UI (Account, Template, Org):
🔍 Auditing (Premium)
All secret usage (set, get, inject) will be logged with:
Example:
💬 Feedback Wanted
coder secret getand script it out?Let us know what you think!
Beta Was this translation helpful? Give feedback.
All reactions