Replies: 6 comments 17 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.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
@michaelbrewer would this proposal help your use case? Note: It's only parameters styling and has nothing to do with the Secrets feature. |
Beta Was this translation helpful? Give feedback.
-
|
As there is no secrets support in coder. Some templates have parameters used for token, that should not be visible to the container. And not in the insights view |
Beta Was this translation helpful? Give feedback.
-
|
So, do you expect a parameter of type The current proposal has secrets scoped to three levels: Account, Template, and Organization. I have a few questions.
|
Beta Was this translation helpful? Give feedback.
-
Does this mean you only want access to them in buildtime (terraform) and not in runtime(container)? |
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.
-
|
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 include support for the devcontainer spec. cc: @f0ssel |
Beta Was this translation helpful? Give feedback.
-
|
@ggjulio, what if we injected all account-level secrets into all running dev containers that the user has? This would allow us to implement them so that users would only need to define them in their Account Settings instead of in the dev container. |
Beta Was this translation helpful? Give feedback.
-
|
@matifali depending on which repo we're working on, a user may not want to inject all their secrets in any devcontainer repositories. But you're right it's seems a good temporary solution for having generic devcontainer templates. |
Beta Was this translation helpful? Give feedback.
-
|
We can consider opting into what secrets to inject into which workspaces as a future enhancement, but initially, if you have a secret set, it will be injected into your workspaces. |
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.
-
|
In our use-case we use Coder as a "Terraform backend" to manage user's OpenStack infrastructure via API. Since the infra can exist longer than the validity of a token, we send OpenStack credentials as Coder parameters to build the infrastructure. As mentioned by mthemis-provenir, having password-type parameter would be definitely very useful. Having the option to set a secret in the user scope might be even better for our use case. My question is how would this work in the template? Are we going to have coder_secret as data source and this would be injected to the provider for example? Could this secret take a whole |
Beta Was this translation helpful? Give feedback.
-
|
Hi, the current plan is to only handle runtime secrets(available inside the workspace) and no build-time secrets. (No access to secrets in Terraform). Supporting build-time secrets is out of scope for this work. If necessary, you can use an alternative secret provider to fetch and use secrets during the workspace builds. |
Beta Was this translation helpful? Give feedback.
-
As Atif mentioned this is currently out of scope for our secrets implementation. We had a similar issue regarding OpenStack in the Discord (not solved yet) but it can be helpful: https://discord.com/channels/747933592273027093/1348645684760547348 |
Beta Was this translation helpful? Give feedback.
-
|
Hi, |
Beta Was this translation helpful? Give feedback.
-
|
Hi there, this is still on the roadmap, and we may get to it sometime in H2 2026. |
Beta Was this translation helpful? Give feedback.
-
Yes, script injection would help with some workflows where I want user-specific keys, but want to reduce human-in-the-loop interaction.
Nope.
I agree with the proposal. It might be nice to have some way to say, "ignore user secrets," but that's not a dealbreaker for me. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
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(Not in scope at this stage)🔧 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