Comment by lmeyerov | Hacker News Reader

Comment by lmeyerov | Hacker News Reader

Parent Full thread

Actions are awesome... but scary as soon as you have a public repos, contractor, rogue employee, etc. They seem to go against security fundamentals. Ex: Actions should allow going into default-deny mode for all basic runtime capabilities and resource use, and only brought back on via RBAC. Today, it's not hard to steal npm/pip/etc creds or get into people's corp runners. Having gone through the browser security policy heyday, this is deja vu, except now for exposing the server side and supply chain.

Ex:

- do not run on any event.. unless user authorized for that event. Same for actions.

- separate out policies and users cannot edit policies unless authorized to do that

- do not get physical/logical resources (runners, disk quota, long runs, ...) unless given

- default-deny network outbound with url safe-listing

That way only trusted users can run them, and a bit harder for them to get hurt when there is a surprising action that they run

The next level would probably be something like sandboxing : allow anyone to run an action , but a sandbox mode can autofail if violated, and have explicit imports/exports to lock down for how it gets used.

A lot possible.. but need to invest in the basics first..

Getting a hold of someone's secrets is not possible just by doing a pull request. It's really only about resource usage, at least when the runners in question provide sufficient isolation (true at least for the Github-hosted ones, or we're all in big trouble).

Unfortunately, using self-hosted runners to provide additional capabilities not supported by Github-hosted ones is basically impossible (for public repos at least) as you can't restrict a runner to an organization or project. Set up a bare-metal runner and it will receive jobs from random forks.

> Getting a hold of someone's secrets is not possible just by doing a pull request

Only if you've configured the actions correctly. I would bet that there is a high number of repositories on both GitLab and GitHub with misconfigured CI pipelines where someone can submit a PR with `env | curl` to grab any secrets defined as environment variables.

GitLab CI, and i suppose Github, allow marking env variables as secrets, making them more complicated to show / exfiltrate.

No, GitLab does not allow marking variables as secrets. They allow "masking" env variables, subject to a bunch of caveats, like your secrets not being multiple lines (e.g. a private key cannot be masked). Even then, the masking is just about log output -- it doesn't prevent a `env | curl` type situation. [0]

The correct mitigation is to ensure that any "secret" variables are marked as "protected" so they can only run on protected branches that are limited to pushes by maintainers. And you'll still need to make sure the masking works in the logs.

They do support integrating with Vault to access secrets in a CI job, but you need to pay them to use that feature. [1]

[0] https://docs.gitlab.com/ee/ci/variables/#mask-a-cicd-variabl...

[1] https://docs.gitlab.com/ee/ci/secrets/

Re: Vault, you can read Vault secrets yourself via their JWT integration.

For GitLab if you don't have at least developer access to the repository (as in you are sending a MR from a fork) that will run in the context of your user, so you don't have access to any secrets configured upstream, etc.

If you have access to a repository you can customize the script to do whatever you want, but there will always be a trace tracking it back to you.

There is a discussion about ultimate security (access only when asked) Vs the convenience of self-service.

You can still avoid that by having people use a fork model, or triggering CD from an external project with tight access.

Putting a burocratic process between ICs will only limit their throughput as in Jenkins paradigm.

The better advice is don't hire people you can't trust

Add one extra command ;-) These can be innocuous if buried in something like unit tests of configs or network behavior, or in a big pr:

logs: `env | base64`

network: `env | gzip | curl`

It should be easy to set most workflows to run sandboxed with almost no capabilities - no secrets access, safelisted network access, safelisted package manager accesses for top 10 langs, etc - so that testing someone's PR isn't scary, and runtime violations make loud noises. The whole 'just disable actions on fork PRs' thing is a great default, but ultimately a figleaf as it's not hard to get someone to run an action.

env doesn't show secret/masked variables ;) you have to pass through echo and a file

Reply on news.ycombinator.com