Comments (12)
If you don't specify this, it defaults to docker anyway, and I agree with the logic that @LongLiveCHIEF has presented it here. I'm happy to set a the default in the module as you've suggested in your first comment @trevor-vaughan and give the user the ability to change it if they wish.
from puppetlabs-docker.
Historically I'm not sure what the motivation was to have them separate and not set a default, but I'll look into it and provide feedback shortly
Can you link to the docs you're referring to?
from puppetlabs-docker.
Yes, it's valid that they could be different depending on the configuration settings.
The docker_group
is allowed to run docker
commands without using sudo
. This can be done even while the socket_group
is root
, allowing tighter security and control of the docker daemon, especially on selinux
enabled systems.
If you make them the same, then anyone who can run any old docker
command, would also be able to run any dockerd
command, also without sudo
. You probably don't want that.
from puppetlabs-docker.
@LongLiveCHIEF Maybe I'm missing something. What docker commands are useful without being able to communicate with the socket? This may be pure user error on my part.
from puppetlabs-docker.
@davejrt The documentation is the dockerd command line docs at https://docs.docker.com/engine/reference/commandline/dockerd/#description
The group
options is "Group for the unix socket" and dockerd
does not connect to TCP or FD by default
Per the Daemon socket option
section
By default, a unix domain socket (or IPC socket) is created at /var/run/docker.sock, requiring either
root
permission, ordocker
group membership.
If you want to prevent the ability to run dockerd
commands, I suppose you could have the daemon listen to 127.0.0.1:2375
by default. I haven't tried the fd
option so that may be what I'm missing.
from puppetlabs-docker.
from puppetlabs-docker.
@davejrt Thanks, I think that will make everything more like users expect.
@LongLiveCHIEF Can you provide an example of this? I'm honestly not following.
From a system set up with the module where vagrant
is in docker_users
and the docker_group
is set:
[root@server01 ~]# ll /var/run/docker.sock
srw-rw----. 1 root root 0 Jan 7 02:57 /var/run/docker.sock
[vagrant@server01 ~]$ docker ps
Cannot connect to the Docker daemon. Is the docker daemon running on this host?
[root@server01 ~]# chgrp dockerroot /var/run/docker.sock
[root@server01 ~]# ll /var/run/docker.sock
srw-rw----. 1 root dockerroot 0 Jan 7 02:57 /var/run/docker.sock
[vagrant@server01 ~]$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
13df051d2333 server01.int.localdomain:5000/custom_nginx_server02 "nginx -g 'daemon off" 5 minutes ago Up 5 minutes 0.0.0.0:8081->80/tcp custom_nginx_server02
681823acca51 custom_nginx_server01 "nginx -g 'daemon off" 5 minutes ago Up 5 minutes 0.0.0.0:80->80/tcp custom_nginx_server01
e7ea608588fa server01.int.localdomain:5000/custom_nginx_server03 "nginx -g 'daemon off" 5 minutes ago Up 5 minutes 0.0.0.0:8082->80/tcp custom_nginx_server03
33935e3b6a2e registry "/entrypoint.sh /etc/" 5 minutes ago Up 5 minutes 0.0.0.0:5000->5000/tcp registry
@LongLiveCHIEF In your opinion, what is the proper method for doing this without allowing write access to the socket and/or what should the module do by default?
I think that what you're getting at is setting up a localhost
TCP connection by default per https://docs.docker.com/engine/security/https/, but that's not the configuration that the module presents out of the box nor is it suggested in the README from what I can tell. Should this be the default?
Honestly, my main use case for the docker_group
is GitLab CI runners and it would be nice to not expose any additional services/ports on my system that I don't have to. Obviously, anyone in the docker
or dockerroot
(RHEL) group is going to be able to do what they like with docker containers and there are no users in that group by default.
from puppetlabs-docker.
This module is still working on catching up on some things, and the daemon settings is a big one of these.
The daemon used to be tied to the docker
client library, but this was broken out a while ago, and is now a completely different command.
In a simplified way of looking at it... socket_group
is tied to dockerd
command usage, whereas docker_group
is tied to docker
command usage.
from puppetlabs-docker.
closing due to #107 being merged
from puppetlabs-docker.
I would like to re-open this since it appears to have gotten reverted per #133
from puppetlabs-docker.
Fixed in PR #133
from puppetlabs-docker.
- The readme and init.pp files still state that the default for $socket_group is undef.
- We try not to restart the Docker daemon randomly (I know, our app teams are learning). This change add -G docker, and I don't believe there's any way for me to work around it (obviously, setting socket_group => undef in my profile doesn't work, since undef doesn't override).
from puppetlabs-docker.
Related Issues (20)
- "docker" fact not working on 23.0.1 HOT 1
- docker-ce and docker-ce-cli version mismatch when the 'version' option set HOT 1
- Error: Failed to apply catalog: No such file or directory - docker HOT 1
- docker-compose download URL is incorrect in versions 2+ due to capitalized "Linux" fact HOT 1
- no working parameter combination for docker 1.x and root_dir
- Automatic image and container updates
- docker::registry fails
- Documentation around supported operating systems HOT 4
- Using Compose with build statement a container is not detected as running and recreated with each run HOT 10
- Docker module doesn't work in AmazonLinux2 HOT 1
- Docker compose restarting service with docker.io/library/ container
- docker_stack incorrectly determines if the stack is deployed HOT 1
- Add option to add ExecReload in the systemd service file
- docker_network needs the ability to add '--attachable' for the overlay driver.
- docker_stack uses outdated way of using psych's YAML.safe_load HOT 1
- Switch to --password-stdin for authentication in docker::registry
- Fact docker fail when podman is installed to emulate docker HOT 2
- v10 uses docker arguments and options in the wrong order.
- Windows install failing because of error with puppetlabs/reboot. HOT 6
- Unpossible to disable icc with 10.x version of this module
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from puppetlabs-docker.