docker
/
docs
mirror of https://github.com/docker/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

added missing code to upgrade to Enable the Docker daemon as a service and then start it 

edited link on emergency access to DTR in adminguide
added message in RN regarding LDAP accepting only lowercase names
added note in accts doc that expanded on RN about first creating a repo before pushing
edits based on convo with mary on RN and accts
added to the RNs about namespace workaround and LDAP auth
release notes for 1.4.1
fixed small typos to RNs
changed word in RN
corrected date in RN to tomorrow
fixed errant numbering

tiny typo in RN--good to go

Signed-off-by: Carol Fager-Higgins <carol.fager-higgins@docker.com>
This commit is contained in:
Carol Fager-Higgins 2015-11-17 12:43:13 -08:00
parent d719ceb3df
commit ebf4db1442
5 changed files with 190 additions and 99 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

129
accounts.md
View File

@ -7,12 +7,21 @@ parent="smn_dhe"
weight=10 weight=10
+++ +++
# Account and repository management introduction # Account and repository management
This document describes the various actions you can perform surrounding account This section explains the relationship between users, organizations, teams, and
and repository management through the Docker Trusted Registry (Trusted Registry) repositories and gives examples of potential workflows you might use. It also
user interface (UI). What you see and do depends on your role and describes the various actions you can perform surrounding account and repository
permissions which is outlined in this document. Use the UI to quickly see, and management through the Docker Trusted Registry (Trusted Registry) user interface
(UI).
There are three scopes with which you can manage permissions:
* organizations
* teams
* repositories
What you see and do depends on your role and permissions. Use the UI to see, and
with the correct permissions do the following: with the correct permissions do the following:
* manage repositories * manage repositories
@ -20,57 +29,36 @@ with the correct permissions do the following:
* create and view teams * create and view teams
* assign members to teams * assign members to teams
**Example**: as a organization owner in the organization-owned repository >**Example**: as a organization owner in the organization-owned repository
Animals repo, you might create multiple teams in your organization. You manage Animals repo, you might create multiple teams in your organization. You manage
the teams access. You give Team Alpha permissions so they can modify, the teams access. You give Team Alpha permissions so they can modify,
delete, and push tags. Team Beta can only view, browse, and pull tags. delete, and push tags. Team Beta can only view, browse, and pull tags.
**Note**: You can perform many functions in the UI as you can from the You can perform many functions in the UI as you can from the command line
command line or API. To see what you can do from a command line or API, refer to interface (CLI) or API. To see what you can do from the CLI or API, refer to the
the API documentation accessed from the Trusted Registry UI. API documentation accessed from the Trusted Registry UI.
There are three scopes with which you can manage permissions:
* Organizations
* Teams
* Repositories
This document explains the relationship between users, organizations, teams,
and repositories and gives examples of potential workflows you might use.
## Accounts ## Accounts
Docker defines two types of accounts: users and organizations. Docker defines two types of accounts: users and organizations.
* Users are individuals. They are sometimes called members in the context of a team or organization. * Users are individuals, and can be called members in the context of a team or organization.
* An organization is a group of members. * An organization is a group of members.
Both accounts are defined by a namespace containing two component names in the Both accounts are defined by a namespace containing two component names in the
form of account-name/repository-name. There is no limit to how many you can have of each type of account. form of account-name/repository-name. There is no limit to how many you can have
of each type of account.
## Repositories ### User accounts
In the Trusted Registry, repositories can be either public or private. Anyone can create them, but who sees and accesses them are determined by permissions as well.
**Public**:
* visible to all accounts in the system
* can only be written to by accounts granted explicit write access
**Private**:
* cannot be discovered by any account unless having explicit read access to it
* can be created by users and organizations
## User accounts
A user (member): A user (member):
* Can belong to an organization
* Be a part of a team that is a part of that organization.
* Belong to more than one team, in more than one organization and have differing roles within those teams.
**Example**: * can belong to an organization.
In team A, they can have admin permissions so they can help manage their group, * be a part of a team that is a part of that organization.
while in team B, those users only have read permission. * belong to more than one team, in more than one organization, and have differing roles within those teams.
So in team A, they can have admin permissions so they can help manage their
group, while in team B, those users only have read permission.
User can also create repositories under their own name and share those User can also create repositories under their own name and share those
repositories with other users. They confer permissions to other users on a repositories with other users. They confer permissions to other users on a
@ -85,7 +73,7 @@ per-repository basis. The following table depicts the combination of users and p
| teams: view public repos, members | x | x | x | x | | | teams: view public repos, members | x | x | x | x | |
| teams: set repo permissions | x | x | | | | | teams: set repo permissions | x | x | | | |
## Organization accounts ### Organization accounts
System administrators can also create an organization account, with its own System administrators can also create an organization account, with its own
namespace of repositories. Comprised of one or more teams, they can be managed namespace of repositories. Comprised of one or more teams, they can be managed
@ -101,17 +89,17 @@ organization.
All organization members can see teams and their members. However, they are not All organization members can see teams and their members. However, they are not
visible to users outside that organization. visible to users outside that organization.
## Teams ### Teams
Teams are configured in two ways: Teams are configured in two ways:
* As a list of users managed by an organization owner, or * as a list of users managed by an organization owner, or
* Through LDAP system integration which can then be periodically synced * through LDAP system integration which can then be periodically synced
The organization owner, other than the system administrator, is the only person The organization owner, other than the system administrator, is the only person
who can create, modify, or delete those teams that belong to that organization. who can create, modify, or delete those teams that belong to that organization.
Teams, like users, can also be granted permissions to their repositories as seen in the following table: Teams, like users, can also be granted permissions to their repositories as seen in the following table:
| Repository access | read | read-write | admin | | Repository access | read | read-write | admin |
|------------------------|:----:|:----------:|:-----:| |------------------------|:----:|:----------:|:-----:|
@ -123,7 +111,40 @@ Teams, like users, can also be granted permissions to their repositories as seen
| make public or private | | | x | | make public or private | | | x |
| manage user access | | | x | | manage user access | | | x |
**Note**: These permissions are additive. This means you cannot override a team level permission to prevent access to a specific repository. If a team has read-write access to the entire namespace of repositories, then granting that team 'read-only' access to a specific repository will not reduce their access to that repository, as the team will still have read-write access to that repository through its namespace access. These permissions are additive. This means you cannot override a team level
permission to prevent access to a specific repository. If a team has read-write
access to the entire namespace of repositories, then granting that team
'read-only' access to a specific repository will not reduce their access to that
repository, as the team will still have read-write access to that repository
through its namespace access.
## Repositories
Any user can create and share public or private repositories. Users that are
designated as org admins (or the Trusted Registry admin) can create and manage
repositories that teams can belong to. One team might have read-write
permissions, while another team could only have read-only permissions. A third
team that is outside that organization (and repository) may not even be able to
even see that repository. This is based on account permissions.
A repository must first exist before users can push an image to it. If they
tried to push an image without designating a repository through the CLI, they
see the following error message:
% docker push my.dtr.host/user1/myimage
The push refers to a repository [my.dtr.host/user1/myimage] (len: 1)
1d073211c498: Image push failed
unauthorized: access to the requested resource is not authorized
A public repository:
* is visible to all accounts in the system
* can only be written to by accounts granted explicit write access
A private repository:
* cannot be discovered by any account unless having explicit read access to it
* can be created by users and organizations
### Working with repositories, organizations, and teams ### Working with repositories, organizations, and teams
@ -131,10 +152,10 @@ From the Trusted Registry dashboard, click the Repositories submenu.
From the Repository submenu, you can: From the Repository submenu, you can:
* View, search, and filter the list of your repositories * view, search, and filter the list of your repositories
* Create either public or private repositories * create either public or private repositories
* Select a repository and edit it * select a repository and edit it
* Drill down to see details, teams that are associated with it, and settings. * drill down to see details, teams that are associated with it, and settings.
There are submenus which you can see additional information: There are submenus which you can see additional information:
@ -144,10 +165,10 @@ There are submenus which you can see additional information:
From the Organizations submenu, you can: From the Organizations submenu, you can:
* Create a new organization * create a new organization
* View, delete, or edit an existing organization * view, delete, or edit an existing organization
* Add teams to it * add teams to it
* View and add members to the team * view and add members to the team
## See also ## See also

2
adminguide.md
View File

@ -110,7 +110,7 @@ example command. >
> >
This gives you access on port `9999` on your Trusted Registry server - This gives you access on port `9999` on your Trusted Registry server -
`http://<dtr-host-ip>:9999/admin/`. `http://<dtr-host-ip>:9999`.
### SSH Access to host ### SSH Access to host

2
install/install-csengine.md
View File

@ -107,7 +107,7 @@ kernel.
$ sudo apt-get install -y linux-image-extra-virtual $ sudo apt-get install -y linux-image-extra-virtual
You may need to reboot your server after updating the LTS kernel. You may need to reboot your server after updating the LTS kernel.
5. Add the repository for the new version: 5. Add the repository for the new version:

25
install/upgrade.md
View File

@ -95,9 +95,18 @@ again.
`$ sudo yum install docker-engine` `$ sudo yum install docker-engine`
6. Restart the Trusted Registry: 6. Enable the Docker daemon as a service and then start it.
`$ sudo bash -c "$(sudo docker run docker/trusted-registry start)"` ```
$ sudo systemctl enable docker.service
$ sudo systemctl start docker.service
```
7. Restart the Trusted Registry:
```
$ sudo bash -c "$(sudo docker run docker/trusted-registry start)"
```
### Ubuntu 14.04 LTS (APT-based systems) ### Ubuntu 14.04 LTS (APT-based systems)
@ -117,7 +126,13 @@ again.
`$ sudo apt-get update && sudo apt-get install apt-transport-https` `$ sudo apt-get update && sudo apt-get install apt-transport-https`
4. Add the repository for the new version: 4. Install additional virtual drivers not in the base image.
$ sudo apt-get install -y linux-image-extra-virtual
You may need to reboot your server after updating the LTS kernel.
5. Add the repository for the new version:
`$ echo "deb https://packages.docker.com/1.9/apt/repo ubuntu-trusty main" | sudo tee /etc/apt/sources.list.d/docker.list` `$ echo "deb https://packages.docker.com/1.9/apt/repo ubuntu-trusty main" | sudo tee /etc/apt/sources.list.d/docker.list`
@ -131,11 +146,11 @@ again.
* ubuntu-vivid (Ubuntu 15.04) * ubuntu-vivid (Ubuntu 15.04)
* ubuntu-wily (Ubuntu 15.10) * ubuntu-wily (Ubuntu 15.10)
5. Install the new package: 6. Install the new package:
`$ sudo apt-get update && sudo apt-get install docker-engine` `$ sudo apt-get update && sudo apt-get install docker-engine`
6. Restart the Trusted Registry: 7. Restart the Trusted Registry:
`$ sudo bash -c "$(sudo docker run docker/trusted-registry start)"` `$ sudo bash -c "$(sudo docker run docker/trusted-registry start)"`

131
release-notes.md
View File

@ -18,6 +18,26 @@ These notes refer to the current and immediately prior releases of Docker
Trusted Registry and the commercially supported Docker Engine. For notes on Trusted Registry and the commercially supported Docker Engine. For notes on
older versions of these, see the [prior release notes archive](prior-release-notes.md). older versions of these, see the [prior release notes archive](prior-release-notes.md).
# Docker Trusted Registry 1.4.1
(24 November 2015)
### Fixed with this release
This release addresses the following issues in Docker Trusted Registry 1.4.0.
* Trusted Registry administrators previously could not pull unlisted repositories in any authorization mode.
* When using LDAP authentication, only users with lowercase letters, numbers, underscores, periods, and hyphens in their usernames in the LDAP server were
synchronized to the Trusted Registry user database. The Trusted Registry now
synchronizes users with usernames containing uppercase letters. If this affects
your organization, perform a LDAP sync from the Trusted Registry UI. Navigate to
Settings > Auth to perform the sync.
* Fixed an issue where Trusted Registry administrators could not list all repositories in the registries. To list them, you must use the `catalog` API using a `bash` shell. The following example lists repositories in a Trusted Registry located at my.dtr.host where the user `admin` has password `password`.
```
bash -c 'host=vagrant.host admin=admin password=password token=$(curl -u $admin:$password -k "https://$host/auth/token?service=$host&scope=registry:catalog:*" | python2 -c "import json,sys;obj=json.load(sys.stdin);print obj[\"token\"]") && curl -k -H "Authorization: Bearer $token" "https://$host/v2/_catalog"'
```
## Docker Trusted Registry 1.4 ## Docker Trusted Registry 1.4
(12 November 2015) (12 November 2015)
@ -44,45 +64,47 @@ documentation.
* Set up, and manage user accounts, teams, organizations, and repositories from either APIs or through the Trusted Registry user interface. Refer to either the API documentation or the [documentation](accounts.md) for performing tasks in the UI. * Set up, and manage user accounts, teams, organizations, and repositories from either APIs or through the Trusted Registry user interface. Refer to either the API documentation or the [documentation](accounts.md) for performing tasks in the UI.
* Search, browse, and discover images created by other users through either APIs or through the Trusted Registry user interface. * Search, browse, and discover images created by other users through either APIs or through the Trusted Registry UI.
* Users, depending on their roles, can access account information through the Trusted Registry user interface. Refer to the [documentation](accounts.md) for details. * Users, depending on their roles, can access account information through the Trusted Registry UI. Refer to the [documentation](accounts.md) for details.
* View new API documentation through the Trusted Registry user interface. As before, you can also view it from the [documentation section](https://docs.docker.com/docker-trusted-registry/). * View new API documentation through the Trusted Registry UI. You can also view this [documentation](https://docs.docker.com/docker-trusted-registry/) from Docker, Inc. docs section.
* New APIs * New APIs
* New APIs for accessing repositories, account management, indexing, searching, and reindexing. * There are new APIs for accessing repositories, account management, indexing, searching, and reindexing.
* You can also view an API and using Swagger UI, click the "Try it out" button to perform the action. This might be useful if you need to reindex. * You can also view an API and using the Swagger UI, click the "Try it out button to perform the action. This might be useful, for example, if you need to reindex.
* Different repository behavior. You must explicitly create (or have it performed for you if you don't have the correct permissions) a repository before pushing to it. This behavior is different than how you would perform this in an unsecured free and open-source software (FOSS) registry. * Different repository behavior. A repository must first exist before you can push an image to it. This means you must explicitly create (or have it performed for you if you don't have the correct permissions) a repository. This behavior is different than how you would perform this in a free and open-source software registry.
* New experimental feature. Docker Trusted Registry now integrates with Docker Content Trust using Notary. This is an experimental feature that is available with this release. See the [configuration documentation](configuration.md). * New experimental feature. Docker Trusted Registry now integrates with Docker Content Trust using Notary. This is an experimental feature that is available with this release. See the [configuration documentation](configuration.md).
### Fixed with this release ### Fixed with this release
This release corrects the following issues in Docker Trusted Registry 1.3.3 This release corrects the following issues in Docker Trusted Registry 1.3.3.
#### LDAP Configuration #### LDAP Configuration
* Performance for LDAP user authenticaiton has been significantly increased, reducing the number of required LDAP requests to only a single BIND request to authenticate a user. * Performance for LDAP user authentication has been significantly improved, reducing the number of required LDAP requests to only a single BIND request to authenticate a user.
* The "Read-Write Search Filter" and "Read-Only Search Filter" fields have been deprecated. You can now create organization accounts and teams in the Trusted Registry to allow for more fine grained access control. Team member lists can be synced with a group in LDAP. * The "Read-Write Search Filter" and "Read-Only Search Filter" fields have been deprecated. You can create organization accounts and teams in the Trusted
Registry to allow for more fine grained access control. Team member lists can be
synced with a group in LDAP.
* An "Admin Password" is now required. Use this password to login as the * An "Admin Password" is required. Use this password to log in as the
user admin in case the Trusted Registry is unable to authenticate you using user admin in case the Trusted Registry is unable to authenticate you using
your LDAP server. This account can be used to login to the Trusted Registry and correct identity and authentication settings. your LDAP server. This account can be used to log in to the Trusted Registry and manage identity and authentication settings.
* Users on your LDAP server are now synced to the Trusted Registry's local * Users on your LDAP server are now synced to the Trusted Registry's local
database using your configured "User Search Filter". Objects in LDAP that match database using your configured "User Search Filter". Objects in LDAP that match
this filter and have a valid "User Login Attribute" are created as a local this filter and have a valid "User Login Attribute" are created as a local
user with the "User Login Attribute" as their username. Only these users are user with the "User Login Attribute" as their username. Only these users are
able to login to Docker Trusted Registry. able to log in to the Trusted Registry.
* The "Admin LDAP DN" must now be specified to identify the group object on your LDAP server. This should be synced to the system administrators list. The "Admin * The "Admin LDAP DN" must be specified to identify the group object on your LDAP server. This should be synced to the system administrators list. The
Group Member Attribute" should be set to the name of the attribute on this group "Admin Group Member Attribute" should be set to the name of the attribute on
object which corresponds to the Distinguished Name of the group member objects. this group object which corresponds to the Distinguished Name of the group
This setting deprecates the old "Admin Search Filter" field. member objects. This setting deprecates the old "Admin Search Filter" field.
#### Other corrected issues #### Other corrected issues
@ -93,7 +115,41 @@ without creating an administrator.
#### Known issues #### Known issues
Organization owners are unable to delete a repository from the UI. You can still delete a repository through the API and a system administrator can still delete a repository from the UI. * Organization owners are unable to delete a repository from the UI. You can still delete a repository through the API and a system administrator can still
delete a repository from the UI.
* When using LDAP authentication, only users with valid usernames in the LDAP server are synchronized to the Trusted Registry user database. A valid username
only contains lowercase letters, numbers, underscores, periods, hyphens, and
begins and ends with an alphanumeric character.
* After upgrading to the Trusted Registry 1.4.0, users will not be able to access images from the Trusted Registry if they were previously created without
using namespaces. Docker recommends upgrading to version 1.4.1. After upgrading,
for any repository that was previously pushed to the Trusted Registry, that is
now inaccessible, a Trusted Registry administrator must make it accessible by
the following steps:
1. If the repository name is not of the form "namespace/repository", then an administrator must pull all of that repository's tags. For example, you might have an image called `devops_nginx`. The following example shows how you would pull it from a Trusted Registry instance located at my.dtr.host.
```
sudo docker pull --all-tags my.dtr.host/devops_nginx
```
2. Create a new repository. In the Trusted Registry dashboard, navigate to Repositories > New repository.
3. Select the account that you want to associate to that repository, and enter a repository name in that field and save. If you do not see the account name you wanted to use, then create a new organization or user first. For the example `devops_nginx`, you could use `devops` as the organization and `nginx` as the repository name.
4. Next, in a `bash` shell, retag all the tags of that repository as seen in the following example:
```
for tag in `sudo docker images | grep my.dtr.host/devops_nginx | awk '{print $2}'`
do sudo docker tag my.dtr.host/devops_nginx:$tag my.dtr.host/devops/nginx:$tag
done
```
5. Push the newly tagged version back to the Trusted Registry as seen in the following example:
`sudo docker push my.dtr.host/devops/nginx`
### Docker Trusted Registry 1.3.3 ### Docker Trusted Registry 1.3.3
(18 September 2015) (amended: 2 November 2015) (18 September 2015) (amended: 2 November 2015)
@ -102,11 +158,11 @@ This release corrects the following issues in Docker Trusted Registry 1.3.2
* Fixed an issue related to LDAP integration for users of Oracle Virtual Directory. * Fixed an issue related to LDAP integration for users of Oracle Virtual Directory.
* Corrected an issue where Docker Trusted Registry would not accept a given certificate if the configured domain was only in the Subject Alternative Names (SANs) field and not in the Common Name (CN) field of the certificate. * Corrected an issue where Docker Trusted Registry would not accept a given certificate if the configured domain was only in the Subject Alternative Names
(SANs) field and not in the Common Name (CN) field of the certificate.
* Docker discovered an issue in which the tokens used in authorization caused a * Docker, Inc. discovered an issue in which the tokens used in authorization caused a break in certain deployments that utilized a load balancer in front of
break in certain deployments that utilized a load balancer in front of multiple multiple Trusted Registry instances to achieve high availability. We regret any
Trusted Registry instances to achieve high availability. Docker regrets any
inconvenience this may have caused you and is working on a future fix. inconvenience this may have caused you and is working on a future fix.
## Commercially Supported Docker Engine ## Commercially Supported Docker Engine
@ -114,27 +170,26 @@ inconvenience this may have caused you and is working on a future fix.
Commercially Supported (CS) Docker Engine is a packaged release that identifies Commercially Supported (CS) Docker Engine is a packaged release that identifies
a release of Docker Engine for which you can receive support from Docker or one a release of Docker Engine for which you can receive support from Docker or one
of its partners. This release is functionally equivalent to the corresponding of its partners. This release is functionally equivalent to the corresponding
Docker Engine release that it references. However, a CS release also includes Docker Engine release that it references. However, a commercially supported
back-ported fixes (security-related and priority defects) from the open source. release also includes back-ported fixes (security-related and priority defects)
It incorporates defect fixes that you can use in environments where new features from the open source. It incorporates defect fixes that you can use in
cannot be adopted as quickly for consistency and compatibility reasons. environments where new features cannot be adopted as quickly for consistency and
compatibility reasons.
### CS Docker Engine 1.9.0 ### Commercially Supported Docker Engine 1.9.0
(12 November 2015) (12 November 2015)
Highlighted Feature Summary: Highlighted feature summary:
* Network Management and Plugins: Networks are now first class objects that can * Network Management and Plugins. Networks are now first class objects that can be listed, created, deleted, inspected, and connected to or disconnected from a
be listed, created, deleted, inspected and connected to or disconnected from a container. They can be manipulated outside of the container themselves and are
container. They can be manipulated outside of the container themselves and are fully manageable on its own lifecycle. You can also use plugins to extend
fully manageable on its own lifecycle. Network functionality can also be network functionality.
extended using plugins.
* Docker now provides support for the in-box Overlay (for cross-host networking) * Docker, Inc. now provides support for the in-box Overlay (for cross-host networking) and Bridge network plugins. You can find more information about how
and Bridge network plugins. You can find more information about how to manage to manage networks and using network plugins in the [documentation](https://docs.docker.com/engine/userguide/networking/dockernetworks/).
networks and using network plugins in the documentation.
* Volume Management and Plugins: Volumes also become discrete, manageable objects in Docker. Volumes can be listed, created, deleted, and inspected. * Volume Management and Plugins. Volumes also become discrete, manageable objects in Docker. Volumes can be listed, created, deleted, and inspected.
Similar to networks, they have their own managed lifecycle outside of the Similar to networks, they have their own managed lifecycle outside of the
container. Plugins allow others to write and extend the functionality of volumes container. Plugins allow others to write and extend the functionality of volumes
or provide integration with other types of storage. or provide integration with other types of storage.
@ -142,9 +197,9 @@ or provide integration with other types of storage.
* The in-box volume driver is included and supported. You can find more information about how to manage volumes and using volume plugins in the * The in-box volume driver is included and supported. You can find more information about how to manage volumes and using volume plugins in the
documentation. documentation.
* Docker Content Trust: Content trust gives you the ability to both verify the integrity and the publisher of all the data received from a registry over any channel. Content Trust is currently only supported using Docker Hub notary servers. * Docker Content Trust. Use Content Trust to both verify the integrity and the publisher of all the data received from a registry over any channel. Content Trust is currently only supported using Docker Hub notary servers.
* Updated the release cadence of CS Docker Engine. Starting with this version, Docker supports **every** major release of Docker Engine from open * Updated the release cadence of the CS Docker engine. Starting with this version, Docker supports **every** major release of Docker engine from open
source with three releases under support at one time. This means you’ll be able source with three releases under support at one time. This means you’ll be able
to take advantage of the latest and greatest features and you won’t have to wait to take advantage of the latest and greatest features and you won’t have to wait
for a supported release to take advantage of a specific feature. for a supported release to take advantage of a specific feature.