Topic on User talk:LarsWirzenius/NewCI/threats

I think we need to rework the definition of roles.

As far as the security context is concerned, we have three (maybe two) roles:

1. The Developer, or anyone who can submit a patchset for CI consumption.
2. The Deployer, or anyone who can merge a patch and deploy the resulting artifact to production. Potentially, they should be able to submit a job manually.
3. The Administrator, or anyone who can, in addition to the Deployer rights, also modify the setup of a job.

Any job generated by actions from the first role must only run in an "untrusted" environment. Jobs generated by actions of people in the remaining roles may run in a trusted environment.

This brings me to the environments definitions.

I think we need to simplify this to two major areas, that can be further divided logically but share the same level of isolation within themselves:

• Trusted environment: anything that is built here is considered safe to run in production. Jobs that run in this environment (builds, tests, artifact upload) must only originate from actions of Deployers or Administrators. Artifacts built here can be used in trusted environments like the kubernetes staging cluster or production.
• Untrusted environment: anything that is built / run here is considered unsafe for production, and should be properly isolated (see below) from the trusted environment. Jobs that run in this environment can originate by any Developer, and artifacts built here cannot be used in the trusted environment, but can be used for testing within the untrusted environment or other environments that are sufficiently isolated from production (e.g. deployment-prep)

And finally, we get to isolation, which is the hardest question. What level of isolation we want to achieve between the trusted and untrusted environments?

I think we need to ensure that nothing that runs in the untrusted environment can infulence things running in the trusted environment. Thus we should ensure that:

• Trusted and untrusted jobs never run on the same host (physical or VM)
• Hosts and jobs in the untrusted environment cannot connect to the trusted environments outside of a predefined whitelist of connections (as an example: connecting to the puppetmaster to get configuration).
• Hosts and jobs in the untrusted environment cannot accept connections from any external source, with the exception of a read-only user interface for the CI system itself, and other connections in a whitelist.
• No confidential, or secret information is accessible from the untrusted environment

I will upload a proposal for an updated diagram soon that should make some of these points clearer.

The diagram for what I described above is available at people.wikimedia.org

> I think we need to ensure that nothing that runs in the untrusted environment can infulence things running in the trusted environment

And as much as possible the rest of production. That is the untrusted environment should be as much unable as possible to reach out to the trusted environment AND production. And on the premise of principle of least privilege, probably the trusted env's access should be on a need-to only basis?