To encrypt GitHub tokens to use them in your .travis.yml you seem to need the Travis CI CLI tool - which I can't install right now.
Therefore I didn't put the GitHub token in my .travis.yml but rather created a new environment variable GITHUB_TOKEN in the repository settings at https://travis-ci.org and use it like this:
github_token: $GITHUB_TOKEN
Now I can use the token to deploy to GitHub releases, for example.
Is this safe? Or are my environment variables in Travis CI somehow publicly accessible?
I found out by now: No, in general, they're not public. Yes, if you follow some rules, it seems perfectly safe to use them for sensitive information. To quote directly from the docs at https://docs.travis-ci.com/user/environment-variables#Defining-Variables-in-Repository-Settings about environment variables:
Define variables in the Repository Settings that (...) contain sensitive data, such as third-party credentials.
Some reasonable rules to keep in mind:
Most importantly: Hide them from the logs with the ON/OFF switch in the settings.
By default, the value of these new environment variables is hidden from the export line in the logs. This corresponds to the behavior of encrypted variables in your .travis.yml. The variables are stored encrypted in our systems, and get decrypted when the build script is generated.
Define them correctly with " if necessary.
These values are used directly in your build, so make sure to escape special characters (for bash) accordingly. In particular, if a value contains spaces, you should put quotes around that value. E.g. my secret passphrase should be written "my secret passphrase".
Also important to know: even if your environment variables are hidden in the logs, someone could still submit a pull request to your repository with malicious code and access the variable this way. Therefore, the variables are not available within builds from pull requests:
Similarly, we do not provide these values to untrusted builds, triggered by pull requests from another repository.
Related
I am setting up Actions in Github, some of them require a Token for authentication. This is the process I follow to generate them, which is detailed in the Actions Docs:
Go to my Account, generate a PAT
Go to the project and add a Secret using that PAT value
Add the variable name in the Action yml file, for example:
env:
# used by semantic-release to authenticate at github and write to master
# I used the developer tab to generate the token and then paste it to several projs
# as a secret
GH_TOKEN: ${{secrets.GH_TOKEN}}
# used by semantic release to authenticate when publishing to npm
# Generate it in NPM (you just need to be registered at npm which is simple)
NPM_TOKEN: ${{secrets.NPM_TOKEN}}
Now, this is rather tedious, even having a single PAT, I'd still need to create a secret per project.
I have noticed though, that if you create an organization, you can create secrets at the ORG level.
Can you do something similar without having an organization? Can you create user secrets? Or maybe there is a way to use the user settings in the Project's Action?
For a public repository, in github actions, assume my action runs on a compute in azure. I am confused on how i can protect the azure auth details if the CI pipeline has to run in azure.
Lets say to use this action, i have to use a secret and i set an environment variable's value to be the secret - have I not lost the point of having a secret? A malicious user can send a PR that prints the value of the environment variable :
user_password: {{secret.USER_PASSWORD}}
User code:
print(os.environment['user_password'])
The malicious user does not have to guess since the workflow is public and he knows which env var has the secret.
Where am i wrong?
GitHub, like other CI providers, redacts most secrets from the logs. It considers a variety of formats and tries to scrub them. However, in general, you should be careful to avoid printing them to the logs because no system is foolproof and not every possible encoding can be considered.
If you're worried about forked repositories trying to access your secrets, they can't; that's specifically not allowed for the reason you describe. So if someone opens a PR against your repository, they won't be able to access the secrets unless the branch is in your repository (in which case, don't grant that person write access to your repo). It's presumed that you'll perform basic code review to catch any malicious code before merging, so a bad actor won't be able to run any code with the secrets for your repository.
In general, though, using environment variables as a way to pass secrets to programs is a best practice, assuming the running system and programs are trusted. Other users on the system cannot see the environment, and in a CI system the system and programs are assumed to be trusted.
Github Secrets provides a way for passing credentials to Github actions, but are they safe enough to be trusted with highly sensitive credentials?
I'm not sure that anyone can really answer that for you. I think it depends how sensitive, and what level of risk you can afford to take.
What I would suggest, if you are concerned about the security of your secrets, is not to use third party GitHub actions directly. Always fork the action and use your fork in workflows. This will prevent the possibility of someone modifying an action you are using to capture secrets and send them to some external server under their control.
Secrets are encrypted environment variables that you create in an organization, repository, or repository environment. The secrets that you create are available to use in GitHub Actions workflows. GitHub uses a libsodium sealed box to help ensure that secrets are encrypted before they reach GitHub and remain encrypted until you use them in a workflow.
For more details see https://docs.github.com/en/actions/security-guides/encrypted-secrets
Add an additional layer of protection by adding org-level access policy and enable reviewer to control env secrets.
The official boilerplate code injects the npm token as follows
NODE_AUTH_TOKEN: ${{secrets.npm_token}}
How do I access and set this variable? I cant find it in the GUI.
Go to your project in Github
Select the Settings tab
Click the Secrets section in the left hand menu
Add a new secret and provide a name (e.g. npm_token) and a value.
In addition to the GUI, you now (January 2020) have a GitHub Actions API(!, still beta though), as announced here.
And it does include a GitHub Actions Secrets API:
Create or update an repository secret:
Creates or updates an organization secret with an encrypted value. Encrypt your secret using LibSodium.
You must authenticate using an access token with the admin:repo scope to use this endpoint.
GitHub Apps must have the secrets organization permission to use this endpoint.
PUT /repos/{owner}/{repo}/actions/secrets/{secret_name}
Get a repository secret
Gets a single secret without revealing its encrypted value.
Anyone with write access to the repository can use this endpoint.
GitHub Apps must have the secrets permission to use this endpoint.
GET /repos/:owner/:repo/actions/secrets/:name
So the GUI is no longer the sole option: you can script and get/set an Actions secret through this new API.
This page is hard to find, but it exists in the official docs here: Creating and using secrets (encrypted variables).
Copied from the docs below for convenience:
Secret names cannot include any spaces. To ensure that GitHub redacts
your secret in logs, avoid using structured data as the values of
secrets, like JSON or encoded Git blobs.
On GitHub, navigate to the main page of the repository.
Under your repository name, click Settings.
In the left sidebar, click Secrets.
Type a name for your secret in the "Name" input box.
Type the value for your secret.
Click Add secret.
The link above has a bit more info around using secrets as well.
I've created a simple CLI that can help you achieve that - https://github.com/unfor19/githubsecrets
This CLI is based on the official API. You can install it with pip or use Docker, read the README.md for more information
VSTS build definition has the option to create a secret variable. How secret is that variable? Is it safe to store the user credentials which is specific to a set of users? Can other users (who are not authorized to do it) can decrypt that variable?
I came across this article.
Assuming users have build modification access then is it possible to decrypt the variable?
Variables stored are as secure as the agent that runs the build and the integrity of your build definition.
Like you said, if a user can modify the Build Definition and has access to the secret they can pass it to a PowerShell or a Curl task etc. Or if the user can take control over a Build Task's script they can iterate all available secrets (build tasks are considered trusted by the Build System).
Consider that everyone who has write-access over the work directories of the agent can access all secrets that are available to the Build Definitions that execute on the build agent. They can change the scripts used by Build Tasks and thus gain the same level of trust. Any build that runs after this change and until a new version of the task is pushed to the agent will be compromised in this scenario. In theory can every build definition "infect" the _tasks folder of the agent as well. Best way to protect against this is to use the Hosted Pool or to regularly reset your agent's VMs.
YAML build definitions combined with Pull-Requests give you more control over the Change/approval process of build definitions.
Using a Variable Library you can reduce the number of people who can add secret variables to their Build Definition.
You must secure the Agent Pools and the Variable Libraries/Build Definitions in such ways that only limited and trusted users can access these resources. Optionally use single-use passwords that expire after a short time or temporarily grant these permissions.
Remember that all changes to Build Definitions and Variable Libraries and Scripts in the Git Repository are tracked.
The alternate ways to get access to the secrets do not apply to Azure DevOps as none have access to the Application Tier in Azure and access is strictly monitored by Microsoft.