Feature request and offer to implement :)

[ncode]

Hi @mxab,

Thanks a lot for your project. It's pretty awesome how much you can extend nomad with it. I'm thinking about having a broader support for acl management in nomad and I could for sure use mutators for that. For it to work I'd need to propagate the token and the client ip to a downstream call during the mutator flow. Is that something you see a fit for the project? I'm happy to send a PR with the implementation if so.

Thanks!

[mxab]

Hi @ncode, thank you so much for the nice feedback.

I think that should be doable.
Assuming that you talk about the "json patch webhook mutator" we would need to send this additional context here:

https://github.com/mxab/nacp/blob/main/admissionctrl/mutator/json_patch_webhook.go#L47C14-L47C18

Currently the signature of the internal Controller/Mutate methods does not include any kind of additional context beside the job
https://github.com/mxab/nacp/blob/main/admissionctrl/controller.go#L61C22-L61C39

I guess creating such a context is possible just not sure if we should just focus on those two values of yours. Also does it make sense to forwards such sensitive information to every remote validator/mutators?

Any toughts?

Just out of curiosity, could you describe your use case a little bit more?

[ncode]

Hi @mxab,

Sure!

Hi @ncode, thank you so much for the nice feedback.

I think that should be doable. Assuming that you talk about the "json patch webhook mutator" we would need to send this additional context here:

https://github.com/mxab/nacp/blob/main/admissionctrl/mutator/json_patch_webhook.go#L47C14-L47C18

That's exactly what I thought!

Currently the signature of the internal Controller/Mutate methods does not include any kind of additional context beside the job https://github.com/mxab/nacp/blob/main/admissionctrl/controller.go#L61C22-L61C39

I guess creating such a context is possible just not sure if we should just focus on those two values of yours. Also does it make sense to forwards such sensitive information to every remote validator/mutators?

Any toughts?

Just out of curiosity, could you describe your use case a little bit more?

Yes. I can give you a few examples:

1. Restrict specific actions based on CIDR, eg: only allow the authenticated user juliano if he's coming from a specifc CIDR on my network to exec into a container
2. Audit logging, using the mutator to do something like token -self and log the accessor id along with the path and maybe payload of the requests. Today you can only have a proper audit tracing if you use enterprise.
3. Implement a finer controlled range of ACL. I'd be able to create a custom policy via mutator that allows an user to stop and start a job, but doesn't allow the user to edit and dispatch.
4. Implement quota management for specific token types defining that a user is only able to spin up X amount of resources

For all of the above scenarios we need as the fist step to resolve the accessor id. Thinking a bit more, if we have a property that's exposes the content of token self and the called address (without propagating the authentication token id), I'd still be able to implement all the examples above.

[mxab]

Yes. I can give you a few examples:

Neat :)

Audit logging

Would it make sense to introduce a new component? I was in general thinking about a generic "side effecter" hook as third step. It could be used for logging but also to potentially to pre provision required infrastructure before the job is initially deployed

For all of the above scenarios we need as the fist step to resolve the accessor id.

So the idea would NACP does a token self lookup for hooks that need it, create a kind of CallerContext which is passed to the mutator/validator.

for the embedded OPA validator the rules would change I guess since it should be part of the input or we could move this context to the data field

[ncode]

Yes. I can give you a few examples:

Neat :)

Audit logging

Would it make sense to introduce a new component? I was in general thinking about a generic "side effecter" hook as third step. It could be used for logging but also to potentially to pre provision required infrastructure before the job is initially deployed

It makes a lot of sense. It becomes a very flexible way of hooking different actions.

For all of the above scenarios we need as the fist step to resolve the accessor id.

So the idea would NACP does a token self lookup for hooks that need it, create a kind of CallerContext which is passed to the mutator/validator.

Yes. The only "downside" is to require an extra call on each request, which sounds pretty ok tbh.

for the embedded OPA validator the rules would change I guess since it should be part of the input or we could move this context to the data field

I'm still building knowledge on OPA, so I can comment later :)

[mxab]

Yes. The only "downside" is to require an extra call on each request, which sounds pretty ok tbh.

I would make it configurable per hook e.g resolveToken = true so if one hook has it the token is resolved but it is only passed to those who marked it like that.

I can try to come up with something but I'm currently traveling so don't expect anything too soon

[ncode]

Yes. The only "downside" is to require an extra call on each request, which sounds pretty ok tbh.

I would make it configurable per hook e.g resolveToken = true so if one hook has it the token is resolved but it is only passed to those who marked it like that.

That's pretty similar to what I had in mind 😄

I can try to come up with something but I'm currently traveling so don't expect anything too soon

No worries. I can also work on it and open a PR, we can discuss the changes required.