Organizations are for shared ownership of repositories. Organizations and the repositories they own are separate from the users who have permissions to the repositories. Specific users may have admin access, while others may have read-only access, and specific teams may have read-write access.

I've created repositories for more of the components of the NerdDinner stack under the nerd-dinner organization:

I can grant access to the repositories to individual users or to teams. The Nerd Dinner Ops team is the group for the admin users that I created in UCP. Those users may push images directly, so they have read-write access to all the repositories:

The Nerd Dinner Testers team only needs read access to the repositories, so they can pull images locally for testing but can't push images to the registry:

How you organize repositories in DTR is up to you. You may put all application repositories under one organization, and have a separate organization for shared components that might be used in many projects—such as NATS and Elasticsearch. This means that shared components can be managed by a dedicated team, who can approve updates and make sure that the same versions are being used by all projects. Project team members have read access, so they can always pull the latest shared images and run their full application stack, but they can only push updates to their project repositories.

DTR has permission levels of none, read, read-write, and admin. They can be applied at the repository level to teams or individual users. The consistent authentication but separate authorization models of DTR and UCP mean that a developer can have full access to pull and push images in DTR but may have only read access to view running containers in UCP.

In a mature workflow, you would not have individual users pushing images—it would all be automated. Your initial push would be from the CI system that built the image, and then you would add layers of provenance to your images, starting with promotion policies.