Can access to Bluemix container registry be access controlled? - docker

I want only the CI tools or dedicated users to have write access to the Bluemix Docker registry. Developer or cloud admin accounts should not have write access to the registry. How can this be done?

You can now issue read-only or read-write tokens for IBM Bluemix Container Registry using the container-registry plugin for the bx command.
Tokens can either be non-expiring (unless revoked) or expire after 24 hours.
The use case of automating access is well covered by the documentation.

At this time it is not possible to have different image access levels for the users in the same cf org.

Security settings for clusters and deployments in IBM Bluemix Container service is documented here: https://console.bluemix.net/docs/containers/cs_security.html#cs_security
It may help you in your requirement ...

Related

How to distribute self-hosted app using a private docker registry?

I'm quite new to Docker, but feel using a Docker image is the best way to distribute a self-hosted SaaS application as simply as possible. I've learned that I can have a private registry for my applications.
How would I provide an authentication mechanism before accessing the image? I would need to create a new set of access credentials after the customer purchases the self-hosted product.
You will need to set-up a token based authentication with the docker registry to allow an external system to manage the log-in trough OAuth2. You will need to have an application that will manage the tokens (issuing and authentication).
The token manager will have configuration (credentials) for each of the customers that are entitled to pull the container.
You can check the docker repository document.

Minimum Privileges for Nexus Private Docker Registry

I have setup a private docker registry on Nexus over http and I am able to pull/push with no issues when I 'docker login' using the nexus administrator account. To maintain security best practices I do not want to be using an administrator account simply to pull and push images so I want to make another account for that purpose.
I have created a role is nexus and granted it 'add' privileges but these seem to be insufficient for the docker login command. Which other privileges are required?
It took a bit of trial and error but it seems that at a minimum you need the following:
Add
Edit
Read
In my case specifically, I used the pre-built repository-view type add, edit and read privileges for my repository.
You'll need to grant the nx-repository-view--* privilege for the docker repository.

How to properly store and share docker host access?

I followed a docker-machine tutorial to setup a docker swarm in the cloud. I had setup a bunch of replicas and life is good. Now I need to give my teammates access to this docker swarm. How do I do that?
Should I share docker certificate files? Can each team member have an individual set of certificate files? Is there any way to setup OAuth or other form of SSO?
The Docker daemon doesn't do any extended client auth.
You can generate certificate's for each client from the CA that signed the swarm certificate, which is probably the minimum you want. Access to Docker is root access to the host so best not to hand out direct access to everyone, or outside of development.
For any extended authentication and authorisation you would need to put a broker between the Docker API and your clients. The easiest way to do this is to use a higher level management platform like Rancher or Shipyard, that can manage the swarm for you.
Mesos/Marathon/Mesosphere and Kubernetes are simliar in function but have more of their own idea of what clustering is.

How to use private quay.io images with fleet and CoreOS

I've been trying to deploy containers with fleet on a CoreOS cluster. However, some of the docker images are privately stored on quay.io requiring a login.
Now I could add a docker login as a precondition to every relevant unit file, but that doesn't seem right. I'm sure there must be a way to store the respective registry credentials somewhere docker can find it when trying to download the image.
Any ideas?
The best way to do this is with a Quay "robot account", which is a separate set of credentials than your regular account. This is helpful for two reasons:
they can be revoked if needed
can be limited to a subset of your repositories
When you make a new robot account, if you click "view credentials", you will get the credentials pre-formatted for common use-cases, such as Docker and Kubernetes.
In this case, you want "Docker Configuration", which is placed at ~/.docker/config.json on the server(s). Docker will automatically use this to authenticate with Quay.io.

Docker Registry vs Docker "Trusted" Registry

I just read the entire docs on securing a private Docker Registry. In addition to this, there seems to be a "Docker Trusted Registry", which is described as:
Docker Trusted Registry (DTR) lets you run and manage your own Docker image storage service, securely on your own infrastructure behind your company firewall.
Furthermore, the doc goes on to list a DTRs features:
An image registry to store, manage, and collaborate on Docker images
Pluggable storage drivers
Configuration options to let you run DTR in your particular enterprise environment.
Easy, transparent upgrades
Logging, usage and system health metrics
But doesn't the "normal" Docker Registry give me these as well?!?
Are these two things really the same, or is DTR some sort of commercialized offering of a Docker Registry? Or something else? I'm so confused!
New features in Docker Trusted Registry are:
Control access and permissions by user or organisation
Web UI to search and browse repos, manage users and setting
Integrate to CI and CD systems to automate workflows
LDAP/AD integration
Flexible storage
support User audit logs
Soft Delete image tags
Garbage collection
DTR is the paid support service for the registry - see https://hub.docker.com/enterprise/
Basically, they help you setup and will give you support down the road. It might have some niceties, otherwise you are left to your own to figure out how to run the registry.

Resources