[WIP] Authenticated agent #1247
Conversation
* NetworkPolicy to allow egress only to orchestrator, kube-dns and the Internet from save-agent pods * Don't automount ServiceAccount token into save-agent pods * Field `Agent.isAuthenticated`
…he save-agent container
|
@sanyavertolet, a good enhancement for save-demo-agent too |
Totally agree, will take a look |
# Conflicts: # save-cloud-common/src/jvmMain/kotlin/com/saveourtool/save/entities/Agent.kt
save-deploy/base-images/Dockerfile
Outdated
| RUN groupadd --gid 1100 save-agent && \ | ||
| groupadd --gid 1200 save-executor && \ | ||
| useradd --uid 1100 --gid 1100 --create-home --shell /bin/sh save-agent && \ | ||
| useradd --uid 1200 --gid 1100 --create-home --shell /bin/sh save-agent && \ | ||
| usermod -aG save-executor save-agent && \ |
There was a problem hiding this comment.
I cannot understand why do we create a new user and remove the key from the pod?
As far as I can see, there are two ways:
- Leave the key in
/var/run/secrets/kubernetes.io/serviceaccount/tokenand forbid the child process of save-agent accessing it (probably create another user as you do here); - Forget about Unix permission system and delegate token management to orchestrating pod.
To my mind second way brings less problems as in case of orchestrator sending token to agent might cause problems with save-demo-agent (it has ktor server running and so we might need to implement auth for ktor server also). What was your idea?
Sorry for bothering and thanks in advance
There was a problem hiding this comment.
The problem with the second approach is that you'd need to reliably detect requests from not-yet-authorized agents and distinguish them from similar requests from a tested tool. One idea (I believe, that's why I've added Agent.isAuthenticated) was to initialize agents with isAuthenticated = false, then these agents would send request for a token (which they would do strictly before starting a tested tool), orchestrator would update isAuthenticated = true and won't return token for any new requests from this agent. However, there is no guarantee that already running tool will be able to mimic as a newly created agent and get the token.
That's why the first approach seemed more viable: The agent would read token from a file, that has restricted access for a user, that runs a tested tool.
There was a problem hiding this comment.
Thanks! Now I got the idea
### What's done: * Made save-agent run tested tool under save-executor user * Made save-demo-agent run demo tool under save-executor user * Added parentUserName and childUserName to agents configuration * Added token key protection if parentUserName is provided
sanyavertolet
changed the base branch from
master
to
feature/authenticated-microservices
(partially TODO):
save-executorCloses #1049