Adding custom docker parameters to container create

[junaid-ebrahim]

I have checked and this feature does not seem to be an existing one. I apologize if I missed it. Here is my proposal, paragraph 1 is my proposal , paragraph 2 is my reasoning and motivation, and paragraph 3 is more detail on the 'how' I suggest it can be done.

I would like to add a widget to the "Docker container template configuration" window , under the Advanced tab , this will be a widget below the "Additional directories to make persistent" widget. The purpose would be to allow the user to add additional docker create parameters to the default ones.

The reason for this is the need to simulate a cloud setup with multi end-devices that behave like an OS, and that requires systemd , either using the standard privileged "runc" runtime with additional custom bindings , or using a custom runtime "sysbox-runc" to run systemd in an unprivileged container. I also managed to get a docker-in-docker and a containerd-in-docker container running (by binding the docker/containerd socket on the host inside the container) allowing me to simulate multi node kubernetes cluster with calico CNI(docker in docker does not work due to overlayfs not supported on overlayfs hence the need for host socket binding). Additionally I was able to add IPA Server and client containers simplifying and automating the creation of users/groups/rbac/hbac rules for this multi node cluster. This allowed me to simulate a custom cloud production environment with rbac and hbac roles so I can simulate not just software/hardware functionality but also operational process and division of security/responsibility, this was great learning experience for me. I have a 24 core 32 gig machine but I doubt I would be able to simulate the same setup using KVM, and even if I could, it would be complex and leave my machine with little resources. It's not perfect and the few issues I encountered were easily fixed on the host e.g. disabling swap for kubernetes on the Host and setting the /sys mount propagation in the Container to shared for calico CNI. I can already think of appliances that could be created from this feature (if the custom settings could be incorporated into the appliance) e.g. IPA Server , IPA Client , Kubernetes Nodes (Master, ETCD , Worker) , HAProxy-KeepAlived loadbalancer

I suggest the proposed widget to allow the user to customize the container create be a simple text widget like the others in the Advanced tab, it should accept json in the official docker json api format. The json text from this field can be converted to a json object and this object can be merged into the params object used in the gns3 server docker_vm.py when calling the container create call. Additional checks can be made to ensure that the GNS3 mandatory fields and binds are not overwritten like Name and Hostname e.t.c. Also, validation can be done using the swagger for the docker json API , but this may be a little complicated since docker json api has multiple versions so docker api version checking has to be done to be perfect, but I think even an old schema would be good enough.

Describe alternatives you've considered
My customization proof of concept was to add a special Env variable in the UI and in the server I added simple code to serialize this variable into json and merge it into the param object before the container create call. This may confuse users since this variable can only be set in the container template and not in the actual container instance itself, hence the suggestion to make it a widget in the template.

I think this feature would be easy to implement , I have looked at the files needed to be edited and it looks easy enough. I will attempt to do it myself once I learn how to setup a build and test environment on my Ubuntu machine. I have to admit that my proof of concept has made it so convenient to simulate custom cloud scenarios that its also keeping me very busy.

I welcome any suggestions/tips/thoughts/criticisms or queries.

[ghost]

I really like that idea and the PRs #3150 and GNS3/gns3-server#1877 to implement that. It gives the user much more control of the container.

But that comes with a price: It also allows him to do dangerous things. For example

{
    "HostConfig": {
        "Binds": [ "/:/host:rw"]
    }
}

will give the user complete read-write access to the host filesystem. That is not a big issue for the GNS3VM, as he has already full access (sudo without password). But it might be undesirable for remote servers, that are not under control of the GNS3 user.

I have no idea how to handle that. Prohibiting using custom binds will prevent useful applications, allowing it will open security holes.

[junaid-ebrahim]

I agree, plus there are alternate ways of binding by using the "Mounts" section as well, plus there may be things other than mounts/binds that could cause the user to intentionally or unintentionally harm the system. This feature makes it easy for the user to do so but note that the user can already bind mount the host hdd in a privileged container , the only thing needed would be knowing the device ids (https://medium.com/kokster/mount-volumes-into-a-running-container-65a967bee3b5)

Here are some suggestions, and they are just merely suggestions as I don't know GNS3 or linux that well.

1. Have a prompt for username and password on the gui that it sends to the server, the server can then check if the user has sudo access before allowing this option, maybe even setting a session variable to indicate as such so any future privileged options on GNS3 can be secured by this mechanism. This would require encryption between the gui and the server obviously.
2. Have a config file on the gns3 server that only root has access to, this config will contain an option to enable this feature.
3. Have a list of Mounts/Binds that will be explicitly allowed or disallowed, have this in a config file that only root has access to. This will not prevent any other options (other than binds) current and future within docker that could cause the user to do something harmful.
4. Have a GNS3 specific username and password for privileged options on the gns3 server, this can act as a kind of "power user" protection mechanism that the installer of GNS3 can use to prevent non-administrative/normal users from using this and maybe other potentially harmful options.

That's all I can think of for now, I would welcome any feedback or alternatives