Disable credential sharing

[erikschul]

I would like to disable credential sharing. I searched the docs but didn't find any setting. Is this possible?

AFAIK, on MacOS, credential sharing is automatic: https://code.visualstudio.com/remote/advancedcontainers/sharing-git-credentials

This is problematic, because I wouldn't like the devcontainer to have any credentials.

[bamurtaugh]

Thanks for opening. I wonder if something like "runArgs": ["--no-creds"] would help. @chrmarti any thoughts?

[erikschul]

I use Remote/SSH with devcontainers (using remote docker host).

It would be nice to configure it in the devcontainer.json, but this wouldn't work if the file is writeable in the devcontainer (a virus could modify it, to gain privileges on next window reload).

An alternative could be the global settings.json, to deny sharing globally (ssh+devcontainers), and allowlist/denylist for certain devcontainer's by name / host by ssh config name. But a devcontainer name could be modified to escalate privileges, although it would require the virus to guess the name.

I don't think runArgs would work, because I frequently use Open this folder in a devcontainer, which opens a new window.

I think the simplest solution is a feature to disable all credential sharing globally (ssh+devcontainers), and not allow local .vscode/settings.json etc. to override it. I'm happy to manually copy/mount credentials where relevant.

[chrmarti]

Git credentials can be controlled in the user settings:

SSH and GPG agents are automatically forwarded. You could shut down the local ssh-agent and gpg-agent if you have these to avoid that.

[erikschul]

@chrmarti

Perhaps most people use devcontainers mainly to have a reproducible and shareable development environment, with little concern for security. For example, on GitHub Codespaces, I assume every codespaces receives a fully privileged GitHub token?

My use case is distinctly different, in that I would want the codespace to have a very fine-grained token, for example only the ability to modify one specific branch, and open a pull-request.

Therefore, I need a way to entirely disable credential sharing (i.e. tokens and agent forwarding). I'll be happy to be manually responsible for injecting the relevant token and gitconfig.

My request is whether this use case can be supported with minimal effort, e.g. global config to disable it.

[cadem]

Git credentials can be controlled in the user settings:

SSH and GPG agents are automatically forwarded. You could shut down the local ssh-agent and gpg-agent if you have these to avoid that.

I have the same problem, but I tried this setting, it doesn't work, and this setting is not designed for this problem. can the problem of stopping credential sharing be resoved by setting?

[vs-code-engineering[bot]]

Hey @chrmarti, this issue might need further attention.

@erikschul, you can help us out by closing this issue if the problem no longer exists, or adding more information.

[chrmarti]

Having a single user setting to disable all credential forwarding makes sense. 👍

[erikschul]

The workaround I'm using is not having any credentials installed on the host. But I'm running into some scenarios where that's a problem.

To reiterate, the issue is that malware in a devcontainer could use your credentials to sign and push a commit, or to use ssh keys to connect to hosts.

The feature request, in order of scope:

1. Global setting to disable all credential sharing (git, ssh, gpg)
2. devcontainer.json-level configuration
3. Instead of just true/false, add dialog, which intercepts the request and allows the user to decide whether to allow it or not. Even when using (hardware) security keys, it's basically not clear where the request is coming from. A dialog would help a lot, similar to how Webauthn works.

[erikschul]

@chrmarti However, I'm now obstructed by this magical behavior again.

I am connecting to a Linux server using VSCode Remote/SSH, and build/connect to several devcontainers on that host. My current flow is that I have SSH/git keys installed on the host, such that the devcontainers cannot commit or connect, and review/commit on the host. That works well.

But I'm now forced to use a git repository using https, and it the credentials are being auto-magically shared with the devcontainer.

I've tried running this on the host:

git config --global credential.helper store
echo 'https://<user>:<pass>@<host>' > ~/.git-credentials

but this credential is immediately shared with the devcontainers.

And there's apparently no way to disable that behavior?

[Ayukjhay]

Sorry

On Thu, Jan 16, 2025, 2:48 AM erikschul @.***> wrote:

@chrmarti https://github.com/chrmarti However, I'm now obstructed by this magical behavior again.

I am connecting to a Linux server using VSCode Remote/SSH, and build/connect to several devcontainers on that host. My current flow is that I have SSH/git keys installed on the host, such that the devcontainers cannot commit or connect, and review/commit on the host. That works well.

But I'm now forced to use a git repository using https, and it the credentials are being auto-magically shared with the devcontainer.

I've tried running this on the host:

git config --global credential.helper store echo 'https://:@' > ~/.git-credentials

but this credential is immediately shared with the devcontainers.

And there's apparently no way to disable that behavior?

— Reply to this email directly, view it on GitHub https://github.com/microsoft/vscode-remote-release/issues/9466#issuecomment-2593699369, or unsubscribe https://github.com/notifications/unsubscribe-auth/BOBEQLNKED7DGAGVHBDW4AD2K2URHAVCNFSM6AAAAABCVO6MHOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOJTGY4TSMZWHE . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[erikschul]

It also isn't sufficient for the devcontainer to configure itself, e.g. with

cat /home/<username>/.vscode-server/data/Machine/settings.json
---
{
        "dev.containers.gitCredentialHelperConfigLocation": "none"
}

because any malware could just overwrite that. It must be configured at the IDE level.

It must be impossible for the devcontainer to obtain any credentials when disabled.

[tschaffter]

I also support adding an option to specify whether users want to forward their SSH and GPG resources to the dev container. One issue with automatically forwarding GPG sockets is that the gpg-agent is only available in restricted mode within the dev container. Additionally, I’m encountering the following issue with GPG inside the dev container:

$ export GPT_TTY=$(tty)
$ echo $GPG_TTY
/dev/pts/0

$ echo test | gpg --clearsign
...
gpg: signing failed: Inappropriate ioctl for device
gpg: [stdin]: clear-sign failed: Inappropriate ioctl for device

One way to isolate the gpg-agent inside the dev container from one installed on the host:

On the host, create or edit this file:

~/.gnupg/gpg-agent.conf

Add the following line:

disable-autostart

Restart the agent:

gpgconf --kill gpg-agent

Rebuilt the dev container.