I'm setting up a self-hosted github runner on a k8s cluster. The runner deployment requires that I supply it a token so that it can link to the proper repository/github account.
There are a lot of examples that I've seen that use a Personal Access Token as a secret resource. It seems like bad practice to use a single user's PAT for what should be a service account token. I am wondering if there are recommended way to use a repository or organization-level token stored as a secret.
Possibly the GITHUB_TOKEN, but this seems too transient as it appears to expire following the completion of a workflow.
Curious about best practices in this case.
You can create a registration token for an organization following this doc.
From this doc Github recommends that you only use self-hosted runners with private repositories. This is because forks of your public repository can potentially run dangerous code on your self-hosted runner machine by creating a pull request that executes the code in a workflow.
Do not store secrets in the host runner When a GitHub Action uses the self-hosted runner, it clones the code in a workdir _work.We must ensure that no secrets (application, system, ..) are accessible in this folder.
For more information follow this doc.
Related
I have a few secrets stored in my repo and I want to access those secrets in workflow on a pull request but, I don't want to use pull_request_target because it gives write access on my repo and it leads to security risk is there anything by which, I can accomplish this task.
After a quick internet search I couldn't seem to find an easy way for my Azure Pipeline to write a custom comment back to the PR that triggered it. Is this possible? Does it require a PAT? I can't use any solution that requires exposing a PAT to a external PR, as they could then easily exfiltrate it.
Sure, you can add comments to the PR on GitHub from Azure pipelines. You can use the GitHub Comment task in your pipeline to easily write comments to the GitHub PR.
With this task, you also need to create a GitHub service connection, or a GitHub Enterprise Server service connection if your repository is hosted on GitHub Enterprise Server, for use on the task.
When creating the GitHub (or GitHub Enterprise Server) service connection, you can choose an authorization method from the optional.
GitHub service connection -- Grant authorization or Personal Access Token
GitHub Enterprise Server service connection -- Personal Access Token, Username and Password or OAuth2
So, a GitHub PAT is not required if the authorization method you choose is not Personal Access Token.
[UPDATE]
If you are worrying about that the service connection would be abused by someone to attack your source code repository, you can do the following things:
On GitHub, you can create a PAT, and limit the permission scopes of this PAT. More details, see "Creating a personal access token".
On Azure DevOps, you can choose Personal Access Token as the authorization method on the service connection, and fill with the PAT that you created in above step. Then you can limit which users, teams and groups, even which pipelines, can use the service connection in the project. More details, you can see "Secure a service connection".
I have a public GitHub repo with some Azure Pipelines yml template files. I want to create a pipeline that uses these templates. I don't want to use an OAuth based service connection, because the whole concept of an OAuth Service Connection is simply ridiculous for a CI/CD environment since the tokens expire and need to be tied to a specific user. I also don't want to use a GitHub PAT because it seems ridiculous to have a PAT (again tied to a specific user) to access a public GitHub repo.
How can I create my pipeline so it is not tied to a specific user?
I would like to have something like this
resources:
repositories:
- repository: templates
type: github
name: APublicGitHubOrg/APublicGitHubRepo
ref: ref/heads/master
extends:
template: TheTemplate.yml
but that doesn't work because endpoint is a required property.
Ok...so how can I create an endpoint for GitHub without tying it to a user or having an expiration?
Unfortunately, Repository templates requires an endpoint, and GitHub repos require a GitHub service connection for authorization, which requires either Grant authorization or Personal access token.
If you really want to this feature, please submit a suggestion at website below, product team will evaluate it carefully:
https://developercommunity.visualstudio.com/content/idea/post.html?space=21
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.