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
+++
# Account and repository management introduction
# Account and repository management
This document describes the various actions you can perform surrounding account
and repository management through the Docker Trusted Registry (Trusted Registry)
user interface (UI). What you see and do depends on your role and
permissions which is outlined in this document. Use the UI to quickly see, and
This section explains the relationship between users, organizations, teams, and
repositories and gives examples of potential workflows you might use. It also
describes the various actions you can perform surrounding account and repository
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:
* manage repositories
@ -20,57 +29,36 @@ with the correct permissions do the following:
* create and view 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
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.
**Note**: You can perform many functions in the UI as you can from the
command line or API. To see what you can do from a command line or API, refer to
the 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.
You can perform many functions in the UI as you can from the command line
interface (CLI) or API. To see what you can do from the CLI or API, refer to the
API documentation accessed from the Trusted Registry UI.
## Accounts
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.
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
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
### User accounts
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**:
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.
* 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.
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
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: set repo permissions | x | x | | | |
## Organization accounts
### Organization accounts
System administrators can also create an organization account, with its own
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
visible to users outside that organization.
## Teams
### Teams
Teams are configured in two ways:
* As a list of users managed by an organization owner, or
* Through LDAP system integration which can then be periodically synced
* as a list of users managed by an organization owner, or
* through LDAP system integration which can then be periodically synced
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.
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 |
|------------------------|:----:|:----------:|:-----:|
@ -123,7 +111,40 @@ Teams, like users, can also be granted permissions to their repositories as seen
| make public or private | | | 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
@ -131,10 +152,10 @@ From the Trusted Registry dashboard, click the Repositories submenu.
From the Repository submenu, you can:
* View, search, and filter the list of your repositories
* Create either public or private repositories
* Select a repository and edit it
* Drill down to see details, teams that are associated with it, and settings.
* view, search, and filter the list of your repositories
* create either public or private repositories
* select a repository and edit it
* drill down to see details, teams that are associated with it, and settings.
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:
* Create a new organization
* View, delete, or edit an existing organization
* Add teams to it
* View and add members to the team
* create a new organization
* view, delete, or edit an existing organization
* add teams to it
* view and add members to the team
## 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 -
`http://<dtr-host-ip>:9999/admin/`.
`http://<dtr-host-ip>:9999`.
### 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
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:

25
install/upgrade.md
View File

@ -95,9 +95,18 @@ again.
`$ 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)
@ -117,7 +126,13 @@ again.
`$ 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`
@ -131,11 +146,11 @@ again.
* ubuntu-vivid (Ubuntu 15.04)
* 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`
6. Restart the Trusted Registry:
7. Restart the Trusted Registry:
`$ 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
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
(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.
* 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 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).
### 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
* 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
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
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
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
Group Member Attribute" should be set to the name of the attribute on this group
object which corresponds to the Distinguished Name of the group member objects.
This setting deprecates the old "Admin Search Filter" field.
* 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
"Admin Group Member Attribute" should be set to the name of the attribute on
this group object which corresponds to the Distinguished Name of the group
member objects. This setting deprecates the old "Admin Search Filter" field.
#### Other corrected issues
@ -93,7 +115,41 @@ without creating an administrator.
#### 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
(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.
* 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
break in certain deployments that utilized a load balancer in front of multiple
Trusted Registry instances to achieve high availability. Docker regrets any
* 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
multiple Trusted Registry instances to achieve high availability. We regret any
inconvenience this may have caused you and is working on a future fix.
## 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
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
Docker Engine release that it references. However, a CS release also includes
back-ported fixes (security-related and priority defects) from the open source.
It incorporates defect fixes that you can use in environments where new features
cannot be adopted as quickly for consistency and compatibility reasons.
Docker Engine release that it references. However, a commercially supported
release also includes back-ported fixes (security-related and priority defects)
from the open source. It incorporates defect fixes that you can use in
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)
Highlighted Feature Summary:
Highlighted feature summary:
* Network Management and Plugins: Networks are now first class objects that can
be listed, created, deleted, inspected and connected to or disconnected from a
container. They can be manipulated outside of the container themselves and are
fully manageable on its own lifecycle. Network functionality can also be
extended using plugins.
* Network Management and Plugins. Networks are now first class objects that can be listed, created, deleted, inspected, and connected to or disconnected from a
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
network functionality.
* Docker now provides support for the in-box Overlay (for cross-host networking)
and Bridge network plugins. You can find more information about how to manage
networks and using network plugins in the documentation.
* 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
to manage networks and using network plugins in the [documentation](https://docs.docker.com/engine/userguide/networking/dockernetworks/).
* 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
container. Plugins allow others to write and extend the functionality of volumes
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
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
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.