Restrict network access of the executed tool

[petertrr]

(https://gvisor.dev/docs/architecture_guide/security/)

A sandbox is not a substitute for a secure architecture.

save-cloud services should either be able to authorize against each other (including agent), or the tested tool should have restricted network access (i.e. being able to communicate only with targets outside of cluster IP range)

Plan:

• Add a NetworkPolicy to allow access from save-agent pods only to main ports of backend, orchestrator and sandbox ([WIP] Authenticated agent #1247)
• Move /actuator and /swagger-ui to a separate management port ([Helm] Set another port as a management port for all JVM services #1342)
• Make requests between services authorized using ServiceAccount tokens ([WIP] authenticated microservices #1238)
• Make requests from save-agent use ServiceAccount token; hide the token from the tested tool (also [WIP] Authenticated agent #1247)

[petertrr]

This also is crucial to keep private tests for contests really private

[petertrr]

More ideas:

• Agent is started by container entrypoint
• Agent requests a token from orchestrator
• Orchestrator marks this agent as authenticated in the database
• Agent stores the token in-memory
• Any new authentication attempts from this container/pod are always 401-ed (ID of the container is always known right after its creation so it should have been stored in the DB by the time processes in the container start network activity). Container IDs are inserted into publicly available data (TestExecutions) only after tests are assigned to an agent, i.e. by that time agent should have started and authenticated.

Service can implement app-to-app authentication using basic auth based on attached secrets. In Kubernetes it can be done using empty ServiceAccounts and TokenReview API

---

Agent pods can have a NetworkPolicy allowing egress to orchestrator and backend pods only, and also to all IPs outside of cluster range.

---

Two users in the save-agent pod: save-agent (uid 1100) and save-executor (uid 1200). All resources for execution are chown-ed for save-executor. The user save-agent is also a member of save-executor group to be able to read execution results. save-agent should launch save-cli as a user save-executor.
Then, it seems, save-agent can use Kubernetes secrets (namely ServiceAccount token mounted using volume projection) without executed tool having access to them.