So I've got a bit of an interesting situation on my hands.
I want to allow an API token to create and manage VMs that it has created but _only_ those. I'm using a terraform integration and I don't want it to by accident go nuts and delete anything it shouldn't delete and I also want to restrict which VMs the people using terraform can operate on.
I've set it up so that the base user has ACLs on /vms and I've added ACLs for the APIToken to /vms/${vmid}
Interestingly enough ${vmid} doesn't have to exist yet! This is good, because it allows us to proactively give permissions to certain ids which the token can then manage.
However if we're talking about many vms this becomes a bit ... annoying.
I'd rather have wildcards in the ACLs so I could say: /vms/102* or similar.
This is a bit of weird ask I guess because its entirely unclear how to properly scope this. But having a way to allow access to a number values at the same time would be great for ACLs.
The other thing I've noticed is that ACLs are cleaned up when a VM its referring to is deleted. While this makes sense usually in this case its a bit problematic because the token will simply lose access to that VMid and I have to manually go in and recreate the permission so the VM can be created again, this is suboptimal.
I think what would be a potential solution to this problem is if I could create a templated ACL that allows for a range of values.
Resource Pools _partially_ solve the problem but only for existing resources not the creation of new resources.
Any ideas on how to solve this using the existing systems would be great
If people agree that having a system in place that allows permanent ACLs for a range of VM ids then I'd be happy to file a feature request.
I want to allow an API token to create and manage VMs that it has created but _only_ those. I'm using a terraform integration and I don't want it to by accident go nuts and delete anything it shouldn't delete and I also want to restrict which VMs the people using terraform can operate on.
I've set it up so that the base user has ACLs on /vms and I've added ACLs for the APIToken to /vms/${vmid}
Interestingly enough ${vmid} doesn't have to exist yet! This is good, because it allows us to proactively give permissions to certain ids which the token can then manage.
However if we're talking about many vms this becomes a bit ... annoying.
I'd rather have wildcards in the ACLs so I could say: /vms/102* or similar.
This is a bit of weird ask I guess because its entirely unclear how to properly scope this. But having a way to allow access to a number values at the same time would be great for ACLs.
The other thing I've noticed is that ACLs are cleaned up when a VM its referring to is deleted. While this makes sense usually in this case its a bit problematic because the token will simply lose access to that VMid and I have to manually go in and recreate the permission so the VM can be created again, this is suboptimal.
I think what would be a potential solution to this problem is if I could create a templated ACL that allows for a range of values.
Resource Pools _partially_ solve the problem but only for existing resources not the creation of new resources.
Any ideas on how to solve this using the existing systems would be great
If people agree that having a system in place that allows permanent ACLs for a range of VM ids then I'd be happy to file a feature request.
Last edited:
