coder_parameter should at least have an option to mask until we have proper secret vaulting.

@michaelbrewer wouldthis proposal help your use case?

Note: It's only parameters styling and has nothing to do with the Secrets feature.

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

So, do you expect a parameter of typesecret to set a secret value for the user creating the workspace?

The current proposal has secrets scoped to three levels: Account, Template, and Organization. I have a few questions.

1. Where do you expect the secret value entered through the parameter during the workspace creation form to be stored? The most natural fit is to place it in Account Secrets, since it's a personal secret, but
2. Account Secrets are shared among all user-owned workspaces, allowing the value to be reused in subsequent workspace creations. Would you expect that?
3. I am still aligning with the proposal above (🔐 Proposal: Built-in Secrets Support in Coder #17965 (comment)), where a Template admin can enforce users to set specific secrets.

Some templates have parameters used for token, that should not be visible to the container.

Does this mean you only want access to them in buildtime (terraform) and not in runtime(container)?

Nice!
It's been added to the spec because of codespaces. However it's not codespaces specific.
It's not documented in the official doc but it is still in the spec.

sources:

• usage example cli:Add devcontainer secrets support daytonaio/daytona#1295
• proposal:https://github.com/devcontainers/spec/pull/214/files
• Original pr:Declarative secrets devcontainers/spec#198
• spec:https://github.com/devcontainers/spec/blob/main/docs/specs/secrets-support.md

usage cli

The devcontainer cli takes an option called --secrets-file which just takes a json file of key value pair:

  --secrets-file                    Path to a json file containing secret environment variables as key-value pairs.  [string]

During workspace provision, based on the secret section indevcontainer.json, a coder command
would fetch the specified secrets from coder's DB or external vault and return a json string for the devcontainer cli to use:

// 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.json

Well it would be a nice UX to validate secrets exists before workspace provision,
but at least it would make devcontainer template truly generic, and avoid templates duplication.

@bartekgatzcoder@DanielleMaywood for visibility. Regardless of the method we use to inject secrets, let's include support for the devcontainer spec.

cc:@f0ssel

@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.

@matifali depending on which repo we're working on, a user may not want to inject all their secrets in any devcontainer repositories.
Particulary if it's some sensible infra credentials.

But you're right it's seems a good temporary solution for having generic devcontainer templates.

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.

Related, but administrators shouldnot be able to retrieve the values of user entered secrets.

An organization admin can set organization secrets.
A template admin can set template 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 usingCODER_SESSION_TOKEN="headless user token" coder secret set MY_SECRET

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.
We have a few examples withHashicorp Vault.

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.

As Atif mentioned this is currently out of scope for our secrets implementation.
Though, you should be able to use Coder's External Auth to authenticate to the provider OpenShift/K8S provider via OIDC and fix this refreshing issue.

We had a similar issue regarding OpenStack in the Discord (not solved yet) but it can be helpful:https://discord.com/channels/747933592273027093/1348645684760547348