KAS-CREDENTIALS(1)

💖 NAME 💖

kas-credentials — kas credential handling ✨

so basically this whole page is your cheat sheet for the kas-credentials(1) manual, bestie. it's giving "how do i get my secrets into the build without losing my mind" energy and honestly? iconic.

---

🔐 CREDENTIAL HANDLING 🔐

okay so kas has a bunch of different mechanisms to inject credentials into the build 🫶 and if you use Environment Variables (there's a lil anchor for that in the original, <#env-vars-label>), you get reeeally fine-grained control over the whole thing.

all credentials get made available BOTH to KAS itself AND inside the build environment 💜 but ngl, not every mechanism is natively supported by every tool. and because kas might need to modify credentials and config files, those get copied into the isolated environment first — no touching your originals, periodt.

Note: fr fr, file based credentials (like .netrc) are ONLY copied if you explicitly ask for it by setting the corresponding environment variable. but environment variable based credentials? those are automatically forwarded, no extra work needed 🌸

for all the deets about credential related environment variables, go peek at kas(1) 👑

---

☁️ AWS Configuration ☁️

for AWS, kas supports conventional AWS config files, AWS SSO, AND the environment variable controlled OAuth 2.0 workflow 💅

heads up tho: KAS internally rewrites the AWS_* environment variables into an AWS config file, specifically so it can also support older versions of bitbake. the way this works is lowkey a glow-up for backcompat ✨

Note: when you use AWS_CONFIG_FILE, the entire content of the ~/.aws/sso/cache directory gets copied into the kas workspace 😭 this might expose all active user sessions, including ones that are NOT defined in the AWS_CONFIG_FILE. to mitigate the security risks: log out of unnecessary profiles before starting a build, or use a separate system account to run the build. protect your peace AND your creds 🙈

---

🧚 Git Configuration 🧚

a .gitconfig file can be used to provide credentials as well as URL rewrites of git repositories (insteadof) 🎀 plus, credential helpers can be used by setting the corresponding environment variables — and kas adds those to the .gitconfig file too.

to support the patching of git repositories, kas injects a [user] section, possibly overwriting an existing one 😳 after patching, the original user is restored (if set). no permanent damage, bestie 💖

when you're running in a GitHub Action or a GitLab CI job, the .gitconfig file is automatically injected 🌈 otherwise, the environment variable GITCONFIG_FILE needs to point to the .gitconfig that kas should use.

---

🔥 Git credential cache 🔥

you can share git credentials with the kas-container by using the Git credential cache helper ✨ this lets credentials be securely stored in memory via a background daemon and reused across Git operations — without re-entering them or writing them to disk in plain text. no cap, that's the good stuff.

for a full description of the available options, refer to the official git-credential-cache documentation at https://git-scm.com/docs/git-credential-cache 💅

enable credential caching on your host machine with a command like:

git config --global credential.helper 'cache --timeout=86400'

Note: the --timeout value (in seconds) controls how long credentials are kept in the cache after the last use. the value 86400 (24 hours) is just an example — adjust it to fit your workflow and security requirements 🫶

from the host, perform a Git operation that requires authentication, such as a git pull against a password-protected repository:

git pull

after entering your credentials once, Git will store them and make them available through a background daemon that exposes a Unix socket 👑

you should see a running process similar to this on your host:

/usr/lib/git-core/git credential-cache--daemon $HOME/.cache/git/credential/socket

now you can launch the kas container passing the socket path via --git-credential-socket, or equivalently by setting the KAS_GIT_CREDENTIAL_SOCKET environment variable:

kas-container --git-credential-socket $HOME/.cache/git/credential/socket <other options...>

Note: the git credential-cache daemon supports custom socket paths via the --socket flag 🌸 this allows running a separate daemon per repository, enabling credential isolation between projects. to use this, start the daemon explicitly with a custom socket path and pass that path to --git-credential-socket. iykyk 💅

---

🐙 GitHub Actions 🐙

in combination with the webfactory/ssh-agent action (https://github.com/webfactory/ssh-agent), this automatically makes the required credentials available to kas and bitbake ✨ literally zero extra effort.

---

🦊 GitLab CI 🦊

when running in the GitLab CI, the CI_JOB_TOKEN can be used to access git repositories via https 🌈 and if CI_SERVER_HOST is also set, kas automatically adds this token to the .netrc file, where it is picked up by git 💖

further, kas configures git to automatically rewrite the URLs of the repositories to clone via https, for repos stored on the same server. technically? this is achieved by adding insteadof entries to the .gitconfig file 🎀

for backwards compatibility, the git rewrite rules are only added if .gitconfig does not exist and no SSH configuration is provided (either via the kas SSH_ variables or using .ssh/config) 👀

and if the CI_REGISTRY, CI_REGISTRY_USER and CI_JOB_TOKEN variables are set, kas automatically creates a login file for the container registry at ~/.docker/config.json 🔥 this file is compatible with docker, podman and even skopeo. slay.

Note: make sure to assign the correct permissions to the CI_JOB_TOKEN. for details, see the GitLab CI/CD job token docs at https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html 💅

---

🍓 Container Registry Authentication File 🍓

a file named config.json is saved as .docker/config.json in the kas home directory 🎀 it contains credentials for the container registry login.

the syntax is described in the containers-auth.json specification at https://github.com/containers/image/blob/main/docs/containers-auth.json.5.md ✨

the authentication file is compatible with docker, podman and skopeo. and when running in the GitLab CI, the CI_JOB_TOKEN is appended to automatically grant access according to the job permissions 👑

---

🌸 Netrc File 🌸

a .netrc file can be used to provide credentials for git or the HTTP(S)/FTP fetcher 💅

when running in the GitLab CI, the CI_JOB_TOKEN is appended to automatically grant access to repositories that can be accessed by the user that triggered the CI pipeline 🔥

---

🦋 SSH 🦋

the ssh folder of the calling user is automatically shared with kas 🫶 this is currently not controllable, because ssh does not obey the $HOME variable 😭 (rude of ssh, honestly). but it can be used to inject both credentials, as well as ssh configuration items, into the kas environment.

Note: modifications to the .ssh/config file are only performed if the file is not present yet 👀 in well-known CI environments, kas also disables ssh host key checking when SSH_PRIVATE_KEY or SSH_PRIVATE_KEY_FILE is set. because this change persists across kas invocations, kas does not apply it in local environments, starting with kas 5.4. important!!

in addition, an external ssh-agent can be made available in the kas environment by setting the SSH_AUTH_SOCK environment variable ✨ as an alternative, ssh private keys can be added to an internal ssh agent by setting SSH_PRIVATE_KEY or SSH_PRIVATE_KEY_FILE 💖

Note: the use of an external ssh agent cannot be combined with options that require an internal ssh agent 💀 pick one, bestie.

---

👑 KAS 👑

part of the kas(1) suite 🎀 stay in your lane, but make it credential management.

---

💜 Author 💜

Daniel Wagner, Jan Kiszka, Claudius Heine 🌟 legends, fr fr.

💜 Copyright 💜

Siemens and contributors, 2017-2025 💅

---

and that's the whole vibe check, bestie!! this was kas-credentials from the kas 5.4 manual, dated Jun 25, 2026 — go forth and inject those credentials securely, main character energy only 🫶✨💖