Document different users for ci and eco part

[ribalba]

Currently we don't really state which user has to run eco-ci as we always assumed that we would run as the user of the ci job. This implies that the ci runner could access the code of the ci run which could pose a potential security risk if the ci runner is compromised on our end. We could harden this by creating a new user that has no access to the ci data but can only read the cpu utilisation and then report on this. There is nothing really stopping eco-ci from working like this we just need to document how this can be done and maybe write a little script.

Request came from Anita

[ArneTR]

For what scenario is this idea?

For Github it does not make any real sense I would argue as the execution environment must be able to read the Github ENV vars ... I foresee this a very niche and hacky implementation.
Furthermore the tool installs quite some packages. This would have to be done then beforehand with a different user ... as said. I forsee hackyness.

For an on-premise case I do not quite understand the need here. Us implementing something that could be seen as "secure" is still a case of trust that is likely not perfect.
The most "trustful" way would be to just clone the repository and run a validated copy of the code. Would it not?

Final question: Am I missing a case or missing something else?

[anitaschuettler]

This is due to me asking if there was a way around having an external tool in a pipeline with root access. That's how we're currently running it and it's foreseeable that this will be a problem once we're in a real customer environment.

(Gitlab, AWS)