I'm running a server with WebProtege 4.0.0 from the docker images as described on the WebProtege github page.
Now I want to access a list of all users, how can I actually do that?
The best thing I've found so far is trying to share a project, type in all the letters individually and write down the names that show up.
I'm not sure if that is the best way, but I connected to the database and extracted the users that way.
docker exec -it webprotege_wpmongo_1 bash # connect to docker containers shell.
mongo # connect to mongodb shell
use webprotege # connect to specific database
db.Users.find().toArray() # find and show all users.
Related
I'm using a Docker machine to host some process such as game servers with friends. I want to give access to CLI of some containers for some users (and only for that), so that they cannot interfer eachothers. I don't want those to be roots on this server.
A solution might be to create users, allow them to perform certains commands in adequation with their containers (such as sudo docker attach ) and let them do everything. I would like to know if there is another, better and proper way to do it so.
Do you have done any experimentation of this kind ?
Thanks.
Why not creating a separate Docker container for each service?
So in other words, You create one container for each friend, and on each container you create a user which is a member in sudo (so your friend will be the root of his own container). Then install openssh-server, and give each of your friends the SSH access data (his username and password) to his container. This way they can do what ever they want, without affecting each other.
Of course do not forget to forward the SSH connection (and any other connections of the services you want) from the host to the container.
Sadly as standing there
Why doesn't Docker support multi-tenancy?
docker doesn't support multi-tenancy so you cannot isolate users from each other.
Edit: one of the possible solutions is to create SSH server in every container and then let your users to connect directly via SSH to container instead of using host machine.
I'm setting up a Golang server with Docker and I want an unprivileged user to launch it inside its container for safety.
Here is the simple Dockerfile I use. I import my binary in the container and set a random UID.
FROM scratch
WORKDIR /app
COPY --chown=1001:1001 my-app-binary my-app-binary
USER 1001
CMD ["/app/my-app-binary"]
If my server listens to port 443, It doesn't work since it requires privileged rights. So my app is running by an unprivileged user as intended.
Nonetheless User 1001 was not properly created. The tutorials I saw tell me to create the user in an intermediate 'builder' container (alpine for instance) and import /etc/passwd from it. I didn't find any example doing what I do. (here one tutorial I followed)
Can someone explains to me why my solution works or what I didn't understand?
DISCLOSURE: In my answer I've used quotes from this blog post. I'm neither the author of this post nor in any way related to the author.
It's expected - containers can run under a user that is not known to the container. Quoting docker run docs:
root (id = 0) is the default user within a container. The image developer can create additional users. Those users are accessible by name. When passing a numeric ID, the user does not have to exist in the container.
-- https://docs.docker.com/engine/reference/#user
It helps you resolve issues like this:
Sometimes, when we run builds in Docker containers, the build creates files in a folder that’s mounted into the container from the host (e.g. the source code directory). This can cause us pain, because those files will be owned by the root user. When an ordinary user tries to clean those files up when preparing for the next build (for example by using git clean), they get an error and our build fails.
-- https://medium.com/redbubble/running-a-docker-container-as-a-non-root-user-7d2e00f8ee15#7d3a
And it's possible because:
Fortunately, docker run gives us a way to do this: the --user parameter. We're going to use it to specify the user ID (UID) and group ID (GID) that Docker should use. This works because Docker containers all share the same kernel, and therefore the same list of UIDs and GIDs, even if the associated usernames are not known to the containers (more on that later).
-- https://medium.com/redbubble/running-a-docker-container-as-a-non-root-user-7d2e00f8ee15#b430
The above applies to USER dockerfile command as well.
Using a UID not known to the container has some gotchas:
Your user will be $HOME-less
What we’re actually doing here is asking our Docker container to do things using the ID of a user it knows nothing about, and that creates some complications. Namely, it means that the user is missing some of the things we’ve learned to simply expect users to have — things like a home directory. This can be troublesome, because it means that all the things that live in $HOME — temporary files, application settings, package caches — now have nowhere to live. The containerised process just has no way to know where to put them.
This can impact us when we’re trying to do user-specific things. We found that it caused problems using gem install (though using Bundler is OK), or running code that relies on ENV['HOME']. So it may mean that you need to make some adjustments if you do either of those things.
Your user will be nameless, too
It also turns out that we can’t easily share usernames between a Docker host and its containers. That’s why we can’t just use docker run --user=$(whoami) — the container doesn't know about your username. It can only find out about your user by its UID.
That means that when you run whoami inside your container, you'll get a result like I have no name!. That's entertaining, but if your code relies on knowing your username, you might get some confusing results.
-- https://medium.com/redbubble/running-a-docker-container-as-a-non-root-user-7d2e00f8ee15#e295
I'm new to Cassandra, and trying to get it going on OpenShift, 3.7 Origin.
I'm starting with a base image from DTR, cassandra:3. My Dockerfile is simply: FROM cassandra:3. During the oc new-app command my cassandra pod goes into a crash loop, the only log message that shows up is Running Cassandra as root user or group is not recommended - please start Cassandra using a different system user. If you really want to force running Cassandra as root, use -R command line option. I'm not able to run as root from OSE anyway, so I'm not trying to force it.
What doesn't make sense is the Dockerfile and deploy-entrypoint.sh don't appear to be running root. (And why would cassandra default to something it doesn't recommend?) I'm happy to extend the Dockerfile as needed to fix this error, but nothing I've tried has worked.
Does anyone know what I missed?
That image appears to expect to be started as root and then use gosu to change to the cassandra user, or be run with uid fixed to that matching the cassandra account created.
Under OpenShift with default security model, it will be forced to run as arbitrary user ID, which this image likely doesn't support.
If you have admin access, you could override security for the deployment to specify that it run as the uid for the cassandra account, then it may work.
On my windows server 2016, I am trying to figure out the run command syntax to run a docker image as a user in my ldap. I read this article, but I am not following it very well (different environments)
Perhaps I am miss understanding the concept all together, but in the end I need to run the container as a specific user in our active directory.
Any links to a well documented run --user examples would be appreciated...
One of the things that is confusing is trying to figure out the UserId and such...
The answer depends on the use case, but may be gMSA authentication would help? Basically, with gMSA authentication, you can add the host OS to an AD domain, and containers running on it can share the privileges to use things like network drive. That way, you don't need to pass credential every time you access them.
MS team has a good write up on it here:
Active Directory Service Accounts for Windows Containers
https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/manage-serviceaccounts
Also, artisticcheese has fantastic walk through.
Enabling integrated Windows Authentication in windows docker container
https://artisticcheese.wordpress.com/2017/09/09/enabling-integrated-windows-authentication-in-windows-docker-container/
Hope this helps.
I am learning docker currently.
one thing that I noticed is that whenever I create a new machine using command :
docker-machine create --driver virtualbox default
& after running this command, if I start my docker-machine using:
docker start default
it will always prompt me with super user mode. i.e I always see # instead of $ in my terminal.
I would like like to know why this is happening?
is there particular requirement?
if possible, can I use normal user mode in this terminal?
any inputs?
thanks in advance.
That's the thing with docker: "security isn't the primary requirement".
So, the not-so nice reality is: by default, when docker is doing something, it happens with root permissions. You actually have to put in "work" in order to not use privileged containers; and to run process not as root.
In essence: one should a good amount of research to understand the risks and solutions around "security of containers"; see here for example.