diff --git a/_topic_map.yml b/_topic_map.yml
index 6f727bd55e..458e881bd8 100644
--- a/_topic_map.yml
+++ b/_topic_map.yml
@@ -177,6 +177,8 @@ Topics:
   File: idling-applications
 - Name: Extending the Kubernetes API with CRDs
   File: crd-extending-api-with-crds
+- Name: Pruning objects
+  File: pruning-objects
 ---
 Name: Networking
 Dir: networking
diff --git a/masters/idling-applications.adoc b/masters/idling-applications.adoc
index cdf6005c79..e285ea8f65 100644
--- a/masters/idling-applications.adoc
+++ b/masters/idling-applications.adoc
@@ -1,4 +1,4 @@
-[id='idling_applications']
+[id='idling-applications']
 = Idling applications
 include::modules/common-attributes.adoc[]
 :context: idling-applications
diff --git a/masters/pruning-objects.adoc b/masters/pruning-objects.adoc
new file mode 100644
index 0000000000..de7468e2f8
--- /dev/null
+++ b/masters/pruning-objects.adoc
@@ -0,0 +1,35 @@
+[id='pruning-objects']
+= Pruning objects
+include::modules/common-attributes.adoc[]
+:context: pruning-objects
+
+toc::[]
+
+{nbsp} +
+Over time, API objects created in {product-title} can accumulate in the etcd
+data store through normal user operations, such as when building and deploying
+applications.
+
+Cluster administrators can periodically prune older versions of objects from the
+cluster that are no longer needed. For example, by pruning images you can delete
+older images and layers that are no longer in use, but are still taking up disk
+space.
+
+include::modules/pruning-basic-operations.adoc[leveloffset=+1]
+include::modules/pruning-groups.adoc[leveloffset=+1]
+include::modules/pruning-deployments.adoc[leveloffset=+1]
+include::modules/pruning-builds.adoc[leveloffset=+1]
+.Additional resources
+- xref:../builds/advanced-build-operations.adoc#builds-build-pruning-advanced-build-operations[Performing advanced builds -> Pruning builds]
+
+include::modules/pruning-images.adoc[leveloffset=+1]
+.Additional resources
+- xref:../registry/accessing-the-registry.adoc#accessing-the-registry[Accessing the registry]
+- xref:../registry/securing-exposing-registry.adoc#securing-exposing-registry[Securing and exposing the registry]
+
+include::modules/pruning-hard-pruning-registry.adoc[leveloffset=+1]
+include::modules/pruning-cronjobs.adoc[leveloffset=+1]
+.Additional resources
+- xref:../nodes/nodes-nodes-jobs.adoc#nodes-nodes-jobs_nodes-nodes-jobs[Running tasks in pods using jobs]
+- xref:../masters/quotas-setting-across-multiple-projects.adoc#setting-quotas-across-multiple-projects[Setting resource quotas across multiple projects]
+- xref:../authentication/using-rbac.adoc#using-rbac[Using RBAC to define and apply permissions]
diff --git a/modules/pruning-basic-operations.adoc b/modules/pruning-basic-operations.adoc
new file mode 100644
index 0000000000..3b783f2b01
--- /dev/null
+++ b/modules/pruning-basic-operations.adoc
@@ -0,0 +1,18 @@
+// Module included in the following assemblies:
+//
+// * masters/pruning-objects.adoc
+
+[id='pruning-basic-operations-{context}']
+= Basic pruning operations
+
+The CLI groups prune operations under a common parent command:
+
+----
+$ oc adm prune <object_type> <options>
+----
+
+This specifies:
+
+- The `<object_type>` to perform the action on, such as `groups`, `builds`,
+`deployments`, or `images`.
+- The `<options>` supported to prune that object type.
diff --git a/modules/pruning-builds.adoc b/modules/pruning-builds.adoc
new file mode 100644
index 0000000000..9df0922835
--- /dev/null
+++ b/modules/pruning-builds.adoc
@@ -0,0 +1,59 @@
+// Module included in the following assemblies:
+//
+// * masters/pruning-objects.adoc
+
+[id='pruning-builds-{context}']
+= Pruning builds
+
+In order to prune builds that are no longer required by the system due to age
+and status, administrators can run the following command:
+
+----
+$ oc adm prune builds [<options>]
+----
+
+.Prune builds CLI configuration options
+[cols="4,8",options="header"]
+|===
+
+|Option |Description
+
+.^|`--confirm`
+|Indicate that pruning should occur, instead of performing a dry-run.
+
+.^|`--orphans`
+|Prune all builds whose Build Configuration no longer exists, status is complete,
+failed, error, or canceled.
+
+.^|`--keep-complete=<N>`
+|Per Build Configuration, keep the last `N` builds whose status is complete (default
+`5`).
+
+.^|`--keep-failed=<N>`
+|Per Build Configuration, keep the last `N` builds whose status is failed, error, or
+canceled (default `1`).
+
+.^|`--keep-younger-than=<duration>`
+|Do not prune any object that is younger than `<duration>` relative to the
+current time (default `60m`).
+|===
+
+To see what a pruning operation would delete:
+
+----
+$ oc adm prune builds --orphans --keep-complete=5 --keep-failed=1 \
+    --keep-younger-than=60m
+----
+
+To actually perform the prune operation:
+
+----
+$ oc adm prune builds --orphans --keep-complete=5 --keep-failed=1 \
+    --keep-younger-than=60m --confirm
+----
+
+[NOTE]
+====
+Developers can enable automatic build pruning by modifying their Build
+Configuration.
+====
diff --git a/modules/pruning-cronjobs.adoc b/modules/pruning-cronjobs.adoc
new file mode 100644
index 0000000000..aa651e41ca
--- /dev/null
+++ b/modules/pruning-cronjobs.adoc
@@ -0,0 +1,12 @@
+// Module included in the following assemblies:
+//
+// * masters/pruning-objects.adoc
+
+[id='pruning-cronjobs-{context}']
+= Pruning cron jobs
+
+Cron jobs can perform pruning of successful jobs, but might not properly handle
+failed jobs. Therefore, the cluster administrator should perform regular cleanup of
+jobs manually. They should also restrict the access to cron jobs to a small
+group of trusted users and set appropriate quota to prevent the cron job from
+creating too many jobs and pods.
diff --git a/modules/pruning-deployments.adoc b/modules/pruning-deployments.adoc
new file mode 100644
index 0000000000..c13b5753b7
--- /dev/null
+++ b/modules/pruning-deployments.adoc
@@ -0,0 +1,55 @@
+// Module included in the following assemblies:
+//
+// * masters/pruning-objects.adoc
+
+[id='pruning-deployments-{context}']
+= Pruning deployments
+
+In order to prune deployments that are no longer required by the system due to
+age and status, administrators can run the following command:
+
+----
+$ oc adm prune deployments [<options>]
+----
+
+.Prune deployments CLI configuration options
+[cols="4,8",options="header"]
+|===
+
+|Option |Description
+
+.^|`--confirm`
+|Indicate that pruning should occur, instead of performing a dry-run.
+
+.^|`--orphans`
+|Prune all deployments that no longer have a Deployment Configuration, has status
+is `Complete` or `Failed`, and has a replica count of zero.
+
+.^|`--keep-complete=<N>`
+|Per Deployment Configuration, keep the last `N` deployments that have a status
+of `Complete` and replica count of zero. (default `5`)
+
+.^|`--keep-failed=<N>`
+|Per  Deployment Configuration, keep the last `N` deployments that have a status
+of `Failed` and replica count of zero. (default `1`)
+
+.^|`--keep-younger-than=<duration>`
+|Do not prune any object that is younger than `<duration>` relative to the
+current time. (default `60m`) Valid units of measurement include nanoseconds
+(`ns`), microseconds (`us`), milliseconds (`ms`), seconds (`s`), minutes (`m`),
+and hours (`h`).
+|===
+
+To see what a pruning operation would delete:
+
+----
+$ oc adm prune deployments --orphans --keep-complete=5 --keep-failed=1 \
+    --keep-younger-than=60m
+----
+
+To actually perform the prune operation:
+
+----
+$ oc adm prune deployments --orphans --keep-complete=5 --keep-failed=1 \
+    --keep-younger-than=60m --confirm
+----
diff --git a/modules/pruning-groups.adoc b/modules/pruning-groups.adoc
new file mode 100644
index 0000000000..19dc7ca010
--- /dev/null
+++ b/modules/pruning-groups.adoc
@@ -0,0 +1,52 @@
+// Module included in the following assemblies:
+//
+// * masters/pruning-objects.adoc
+
+[id='pruning-groups-{context}']
+= Pruning groups
+
+To prune groups records from an external provider, administrators can run the
+following command:
+
+----
+$ oc adm prune groups \
+    --sync-config=path/to/sync/config [<options>]
+----
+
+.Prune groups CLI configuration options
+[cols="4,8",options="header"]
+|===
+
+|Options |Description
+
+.^|`--confirm`
+|Indicate that pruning should occur, instead of performing a dry-run.
+
+.^|`--blacklist`
+|Path to the group blacklist file.
+
+.^|`--whitelist`
+|Path to the group whitelist file.
+
+.^|`--sync-config`
+|Path to the synchronization configuration file.
+|===
+
+To see the groups that the prune command deletes:
+
+----
+$ oc adm prune groups --sync-file=ldap-sync-config.yaml
+----
+
+To perform the prune operation:
+
+----
+$ oc adm prune groups --sync-file=ldap-sync-config.yaml --confirm
+----
+
+////
+Needs "Additional resources" links when converted:
+
+xref:../install_config/syncing_groups_with_ldap.adoc#configuring-ldap-sync[Configuring LDAP Sync]
+xref:../install_config/syncing_groups_with_ldap.adoc#overview[Syncing Groups With LDAP]
+////
diff --git a/modules/pruning-hard-pruning-registry.adoc b/modules/pruning-hard-pruning-registry.adoc
new file mode 100644
index 0000000000..f1583d7774
--- /dev/null
+++ b/modules/pruning-hard-pruning-registry.adoc
@@ -0,0 +1,177 @@
+// Module included in the following assemblies:
+//
+// * masters/pruning-objects.adoc
+
+[id='pruning-hard-pruning-registry-{context}']
+= Hard pruning the registry
+
+The OpenShift Container Registry can accumulate blobs that are not referenced by
+the {product-title} cluster's etcd. The basic pruning images procedure,
+therefore, is unable to operate on them. These are called _orphaned blobs_.
+
+Orphaned blobs can occur from the following scenarios:
+
+- Manually deleting an image with `oc delete image <sha256:image-id>` command,
+which only removes the image from etcd, but not from the registry's storage.
+
+- Pushing to the registry initiated by `docker` daemon failures, which causes some
+blobs to get uploaded, but the image manifest (which is uploaded as the very
+last component) does not. All unique image blobs become orphans.
+
+- {product-title} refusing an image because of quota restrictions.
+
+- The standard image pruner deleting an image manifest, but is interrupted before
+it deletes the related blobs.
+
+- A bug in the registry pruner, which fails to remove the intended blobs, causing
+the image objects referencing them to be removed and the blobs becoming orphans.
+// Find this BZ
+
+_Hard pruning_ the registry, a separate procedure from basic image pruning,
+allows cluster administrators to remove orphaned blobs. You should hard prune if
+you are running out of storage space in your OpenShift Container Registry and
+believe you have orphaned blobs.
+
+This should be an infrequent operation and is necessary only when you have
+evidence that significant numbers of new orphans have been created. Otherwise,
+you can perform standard image pruning at regular intervals, for example, once a
+day (depending on the number of images being created).
+
+.Procedure
+
+To hard prune orphaned blobs from the registry:
+
+. *Log in.*
++
+Log in to the cluster with the CLI as a user with an access token.
+
+. *Run a basic image prune*.
++
+Basic image pruning removes additional images that are no longer needed. The
+hard prune does not remove images on its own. It only removes blobs stored in
+the registry storage. Therefore, you should run this just before the hard prune.
+
+. *Switch the registry to read-only mode.*
++
+If the registry is not running in read-only mode, any pushes happening at the
+same time as the prune will either:
++
+--
+- fail and cause new orphans, or
+- succeed although the images cannot be pulled (because some of the
+referenced blobs were deleted).
+--
++
+Pushes will not succeed until the registry is switched back to read-write mode.
+Therefore, the hard prune must be carefully scheduled.
++
+To switch the registry to read-only mode:
+
+.. Set the following environment variable:
++
+----
+$ oc set env -n default \
+    dc/docker-registry \
+    'REGISTRY_STORAGE_MAINTENANCE_READONLY={"enabled":true}'
+----
+
+.. By default, the registry automatically redeploys when the previous step
+completes; wait for the redeployment to complete before continuing. However, if
+you have disabled these triggers, you must manually redeploy the registry so
+that the new environment variables are picked up:
++
+----
+$ oc rollout -n default \
+    latest dc/docker-registry
+----
+
+. *Add the `system:image-pruner` role.*
++
+The service account used to run the registry instances requires additional
+permissions in order to list some resources.
+
+.. Get the service account name:
++
+----
+$ service_account=$(oc get -n default \
+    -o jsonpath=$'system:serviceaccount:{.metadata.namespace}:{.spec.template.spec.serviceAccountName}\n' \
+    dc/docker-registry)
+----
+
+.. Add the `system:image-pruner` cluster role to the service account:
++
+----
+$ oc adm policy add-cluster-role-to-user \
+    system:image-pruner \
+    ${service_account}
+----
+
+. *(Optional) Run the pruner in dry-run mode.*
++
+To see how many blobs would be removed, run the hard pruner in dry-run mode. No
+changes are actually made:
++
+----
+$ oc -n default \
+    exec -i -t "$(oc -n default get pods -l deploymentconfig=docker-registry \
+    -o jsonpath=$'{.items[0].metadata.name}\n')" \
+    -- /usr/bin/dockerregistry -prune=check
+----
++
+Alternatively, to get the exact paths for the prune candidates, increase the
+logging level:
++
+----
+$ oc -n default \
+    exec "$(oc -n default get pods -l deploymentconfig=docker-registry \
+      -o jsonpath=$'{.items[0].metadata.name}\n')" \
+    -- /bin/sh \
+    -c 'REGISTRY_LOG_LEVEL=info /usr/bin/dockerregistry -prune=check'
+----
++
+.Truncated sample output
+----
+$ oc exec docker-registry-3-vhndw \
+    -- /bin/sh -c 'REGISTRY_LOG_LEVEL=info /usr/bin/dockerregistry -prune=check'
+
+time="2017-06-22T11:50:25.066156047Z" level=info msg="start prune (dry-run mode)" distribution_version="v2.4.1+unknown" kubernetes_version=v1.6.1+$Format:%h$ openshift_version=unknown
+time="2017-06-22T11:50:25.092257421Z" level=info msg="Would delete blob: sha256:00043a2a5e384f6b59ab17e2c3d3a3d0a7de01b2cabeb606243e468acc663fa5" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6
+time="2017-06-22T11:50:25.092395621Z" level=info msg="Would delete blob: sha256:0022d49612807cb348cabc562c072ef34d756adfe0100a61952cbcb87ee6578a" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6
+time="2017-06-22T11:50:25.092492183Z" level=info msg="Would delete blob: sha256:0029dd4228961086707e53b881e25eba0564fa80033fbbb2e27847a28d16a37c" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6
+time="2017-06-22T11:50:26.673946639Z" level=info msg="Would delete blob: sha256:ff7664dfc213d6cc60fd5c5f5bb00a7bf4a687e18e1df12d349a1d07b2cf7663" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6
+time="2017-06-22T11:50:26.674024531Z" level=info msg="Would delete blob: sha256:ff7a933178ccd931f4b5f40f9f19a65be5eeeec207e4fad2a5bafd28afbef57e" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6
+time="2017-06-22T11:50:26.674675469Z" level=info msg="Would delete blob: sha256:ff9b8956794b426cc80bb49a604a0b24a1553aae96b930c6919a6675db3d5e06" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6
+...
+Would delete 13374 blobs
+Would free up 2.835 GiB of disk space
+Use -prune=delete to actually delete the data
+----
+
+. *Run the hard prune.*
++
+Execute the following command inside one running instance of a `docker-registry`
+pod to run the hard prune:
++
+----
+$ oc -n default \
+    exec -i -t "$(oc -n default get pods -l deploymentconfig=docker-registry -o jsonpath=$'{.items[0].metadata.name}\n')" \
+    -- /usr/bin/dockerregistry -prune=delete
+----
++
+.Sample output
+----
+$ oc exec docker-registry-3-vhndw \
+    -- /usr/bin/dockerregistry -prune=delete
+
+Deleted 13374 blobs
+Freed up 2.835 GiB of disk space
+----
+
+. *Switch the registry back to read-write mode.*
++
+After the prune is finished, the registry can be switched back to read-write
+mode by executing:
++
+----
+$ oc set env -n default dc/docker-registry REGISTRY_STORAGE_MAINTENANCE_READONLY-
+----
diff --git a/modules/pruning-images.adoc b/modules/pruning-images.adoc
new file mode 100644
index 0000000000..5dd4e16a39
--- /dev/null
+++ b/modules/pruning-images.adoc
@@ -0,0 +1,359 @@
+// Module included in the following assemblies:
+//
+// * masters/pruning-objects.adoc
+
+[id='pruning-images-{context}']
+= Pruning images
+
+In order to prune images that are no longer required by the system due to age,
+status, or exceed limits, administrators can run the following command:
+
+----
+$ oc adm prune images [<options>]
+----
+
+Currently, to prune images you must first log in to the CLI as a user with an
+access token. The user must also have the cluster role `system:image-pruner` or
+greater (for example, `cluster-admin`).
+
+Pruning images removes data from the integrated registry unless
+`--prune-registry=false` is used. For this operation to work properly, the
+registry must be configured with `storage:delete:enabled` set to `true`.
+
+Pruning images with the `--namespace` flag does not remove images, only image
+streams. Images are non-namespaced resources. Therefore, limiting pruning to a
+particular namespace makes it impossible to calculate their current usage.
+
+By default, the integrated registry caches blobs metadata to reduce the number
+of requests to storage, and increase the speed of processing the request.
+Pruning does not update the integrated registry cache. Images pushed after
+pruning that contain pruned layers will be broken, because the pruned layers
+that have metadata in the cache will not be pushed. Therefore, it is necessary
+to clear the cache after pruning. This can be accomplished by redeploying the
+registry:
+
+----
+$ oc rollout latest dc/docker-registry
+----
+
+If the integrated registry uses a Redis cache, you must clean the database
+manually.
+
+If redeploying the registry after pruning is not an option, then you must
+permanently disable the cache.
+
+.Prune images CLI configuration options
+[cols="4,8",options="header"]
+|===
+
+|Option |Description
+
+.^|`--all`
+|Include images that were not pushed to the registry, but have been mirrored by
+pullthrough. This is on by default. To limit the pruning to images that were
+pushed to the integrated registry, pass `--all=false`.
+
+.^|`--certificate-authority`
+|The path to a certificate authority file to use when communicating with the
+{product-title}-managed registries. Defaults to the certificate authority data
+from the current user's configuration file. If provided, a secure connection is
+initiated.
+
+.^|`--confirm`
+|Indicate that pruning should occur, instead of performing a dry-run. This
+requires a valid route to the integrated container image registry. If this
+command is run outside of the cluster network, the route must be be provided
+using `--registry-url`.
+
+.^|`--force-insecure`
+|Use caution with this option. Allow an insecure connection to the container
+registry that is hosted via HTTP or has an invalid HTTPS certificate.
+
+.^|`--keep-tag-revisions=<N>`
+|For each image stream, keep up to at most `N` image revisions per tag (default
+`3`).
+
+.^|`--keep-younger-than=<duration>`
+|Do not prune any image that is younger than `<duration>` relative to the
+current time. Do not prune any image that is referenced by any other object that
+is younger than `<duration>` relative to the current time (default `60m`).
+
+.^|`--prune-over-size-limit`
+|Prune each image that exceeds the smallest limit defined in the same project.
+This flag cannot be combined with `--keep-tag-revisions` nor
+`--keep-younger-than`.
+
+.^|`--registry-url`
+|The address to use when contacting the registry. The command attempts to use a
+cluster-internal URL determined from managed images and image streams. In case
+it fails (the registry cannot be resolved or reached), an alternative route that
+works needs to be provided using this flag. The registry host name can be
+prefixed by `https://` or `http://` which enforces particular connection
+protocol.
+
+.^|`--prune-registry`
+|In conjunction with the conditions stipulated by the other options, this option
+controls whether the data in the registry corresponding to the {product-title}
+image API object is pruned. By default, image pruning processes both the image
+API objects and corresponding data in the registry. This options is useful when
+you are only concerned with removing etcd content, possibly to reduce the number
+of image objects (but are not concerned with cleaning up registry storage) or
+intend to do that separately by hard pruning the registry, possibly during an
+appropriate maintenance window for the registry.
+|===
+
+[id='pruning-images-conditions-{context}']
+== Image prune conditions
+
+* Remove any image "managed by {product-title}" (images with the annotation
+`openshift.io/image.managed`) that was created at least `--keep-younger-than`
+minutes ago and is not currently referenced by:
+- any Pod created less than `--keep-younger-than` minutes ago.
+- any image stream created less than `--keep-younger-than` minutes ago.
+- any running Pods.
+- any pending Pods.
+- any Replication Controllers.
+- any Deployment Configurations.
+- any Build Configurations.
+- any Builds.
+- the `--keep-tag-revisions` most recent items in `stream.status.tags[].items`.
+
+* Remove any image "managed by {product-title}" (images with the annotation
+`openshift.io/image.managed`) that is exceeding the smallest limit defined in
+the same project and is not currently referenced by:
+- any running Pods.
+- any pending Pods.
+- any Replication Controllers.
+- any Deployment Configurations.
+- any Build Configurations.
+- any Builds.
+
+* There is no support for pruning from external registries.
+
+* When an image is pruned, all references to the image are removed from all
+image streams that have a reference to the image in `status.tags`.
+
+* Image layers that are no longer referenced by any images are removed.
+
+[NOTE]
+====
+The `--prune-over-size-limit` flag cannot be combined with
+`--keep-tag-revisions` nor `--keep-younger-than` flags. Doing so returns
+information that this operation is not allowed.
+====
+
+Separating the removal of {product-title} image API objects and image data from
+the Registry by using `--prune-registry=false` followed by hard pruning the
+registry narrows some timing windows and is safer when compared to trying to
+prune both through one command. However, timing windows are not completely
+removed.
+
+For example, you can still create a Pod referencing an image as pruning
+identifies that image for pruning. You should still keep track of an API Object
+created during the pruning operations that might reference images, so you can
+mitigate any references to deleted content.
+
+Also, keep in mind that re-doing the pruning without the `--prune-registry` option or with
+`--prune-registry=true` does not lead to pruning the associated storage in the image registry
+for images previously pruned by `--prune-registry=false`.
+Any images that were pruned with `--prune-registry=false` can only be deleted from
+registry storage by hard pruning the registry.
+
+[id='pruning-images-running-operation-{context}']
+== Running the image prune operation
+
+.Procedure
+
+. To see what a pruning operation would delete:
+
+.. Keeping up to three tag revisions, and keeping resources (images, image
+streams and Pods) younger than sixty minutes:
++
+----
+$ oc adm prune images --keep-tag-revisions=3 --keep-younger-than=60m
+----
+
+.. Pruning every image that exceeds defined limits:
++
+----
+$ oc adm prune images --prune-over-size-limit
+----
+
+. To actually perform the prune operation with the options from the previous step:
++
+----
+$ oc adm prune images --keep-tag-revisions=3 --keep-younger-than=60m --confirm
+----
++
+----
+$ oc adm prune images --prune-over-size-limit --confirm
+----
+
+[id='pruning-images-secure-insecure-{context}']
+== Using secure or insecure connections
+
+The secure connection is the preferred and recommended approach. It is done over
+HTTPS protocol with a mandatory certificate verification. The `prune` command
+always attempts to use it if possible. If it is not possible, in some cases it
+can fall-back to insecure connection, which is dangerous. In this case, either
+certificate verification is skipped or plain HTTP protocol is used.
+
+The fall-back to insecure connection is allowed in the following cases unless
+`--certificate-authority` is specified:
+
+. The `prune` command is run with the `--force-insecure` option.
+. The provided `registry-url` is prefixed with the `http://` scheme.
+. The provided `registry-url` is a local-link address or `localhost`.
+. The configuration of the current user allows for an insecure connection. This
+can be caused by the user either logging in using `--insecure-skip-tls-verify`
+or choosing the insecure connection when prompted.
+
+[IMPORTANT]
+====
+If the registry is secured by a certificate authority different from the one
+used by {product-title}, it must be specified using the
+`--certificate-authority` flag. Otherwise, the `prune` command fails with an
+error.
+====
+
+[id='pruning-images-problems-{context}']
+== Image pruning problems
+
+[discrete]
+[id='pruning-images-not-being-pruned-{context}']
+==== Images not being pruned
+
+If your images keep accumulating and the `prune` command removes just a small
+portion of what you expect, ensure that you understand the image prune
+conditions that must apply for an image to be considered a candidate for
+pruning.
+
+Ensure that images you want removed occur at higher positions in each tag
+history than your chosen tag revisions threshold. For example, consider an old
+and obsolete image named `sha:abz`. By running the following command in
+namespace `N`, where the image is tagged, the image is tagged three times in a
+single image stream named `myapp`:
+
+----
+$ image_name="sha:abz"
+$ oc get is -n N -o go-template='{{range $isi, $is := .items}}{{range $ti, $tag := $is.status.tags}}'\
+  '{{range $ii, $item := $tag.items}}{{if eq $item.image "'"${image_name}"\
+  $'"}}{{$is.metadata.name}}:{{$tag.tag}} at position {{$ii}} out of {{len $tag.items}}\n'\
+  '{{end}}{{end}}{{end}}{{end}}'
+myapp:v2 at position 4 out of 5
+myapp:v2.1 at position 2 out of 2
+myapp:v2.1-may-2016 at position 0 out of 1
+----
+
+When default options are used, the image is never pruned because it occurs at
+position `0` in a history of `myapp:v2.1-may-2016` tag. For an image to be
+considered for pruning, the administrator must either:
+
+* Specify `--keep-tag-revisions=0` with the `oc adm prune images` command.
++
+[CAUTION]
+====
+This action effectively removes all the tags from all the namespaces with
+underlying images, unless they are younger or they are referenced by objects
+younger than the specified threshold.
+====
+
+* Delete all the `istags` where the position is below the revision threshold,
+which means `myapp:v2.1` and `myapp:v2.1-may-2016`.
+
+* Move the image further in the history, either by running new Builds pushing to
+the same `istag`, or by tagging other image. Unfortunately, this is not always
+desirable for old release tags.
+
+Tags having a date or time of a particular image's Build in their names should
+be avoided, unless the image must be preserved for an undefined amount of time.
+Such tags tend to have just one image in its history, which effectively prevents
+them from ever being pruned.
+
+[discrete]
+[id='pruning-images-secure-against-insecure-{context}']
+==== Using a secure connection against insecure registry
+
+If you see a message similar to the following in the output of the `oadm prune
+images` command, then your registry is not secured and the `oadm prune images`
+client attempts to use a secure connection:
+
+----
+error: error communicating with registry: Get https://172.30.30.30:5000/healthz: http: server gave HTTP response to HTTPS client
+----
+
+. The recommend solution is to secure the registry. Otherwise, you can force the
+client to use an insecure connection by appending `--force-insecure`  to the
+command, however this is not recommended.
+
+[discrete]
+[id='pruning-images-insecure-against-secure-{context}']
+==== Using an insecure connection against a secured registry
+
+If you see one of the following errors in the output of the `oadm prune images`
+command, it means that your registry is secured using a certificate signed by a
+certificate authority other than the one used by `oadm prune images` client for
+connection verification:
+
+----
+error: error communicating with registry: Get http://172.30.30.30:5000/healthz: malformed HTTP response "\x15\x03\x01\x00\x02\x02"
+error: error communicating with registry: [Get https://172.30.30.30:5000/healthz: x509: certificate signed by unknown authority, Get http://172.30.30.30:5000/healthz: malformed HTTP response "\x15\x03\x01\x00\x02\x02"]
+----
+
+By default, the certificate authority data stored in the user's configuration
+file are used; the same is true for for communication with the master API.
+
+Use the `--certificate-authority` option to provide the right certificate
+authority for the container image registry server.
+
+[discrete]
+[id='pruning-images-wrong-ca-{context}']
+==== Using the wrong certificate authority
+
+The following error means that the certificate authority used to sign the
+certificate of the secured container image registry is different than the
+authority used by the client:
+
+----
+error: error communicating with registry: Get https://172.30.30.30:5000/: x509: certificate signed by unknown authority
+----
+
+Make sure to provide the right one with the flag `--certificate-authority`.
+
+As a workaround, the `--force-insecure` flag can be added instead. However, this
+is not recommended.
+
+////
+Links needed for "Additional resources" list once converted:
+
+xref:../cli_reference/get_started_cli.adoc#basic-setup-and-login[log in to the
+CLI] as a user with an
+xref:../architecture/additional_concepts/authentication.adoc#oauth[access
+token]. The user must also have the
+xref:../architecture/additional_concepts/authorization.adoc#roles[cluster role]
+*system:image-pruner* or greater (for example, *cluster-admin*).
+
+xref:../install_config/registry/extended_registry_configuration.adoc#docker-registry-configuration-reference-storage[registry is configured]
+
+xref:../install_config/registry/extended_registry_configuration.adoc#docker-registry-configuration-reference-redis[redis
+cache],
+
+xref:../install_config/registry/extended_registry_configuration.adoc#docker-registry-configuration-reference-cache[permanently
+disable the cache].
+
+xref:../install_config/registry/extended_registry_configuration.adoc#docker-registry-configuration-reference-cache[permanently
+disable the cache].
+
+See
+xref:pruning-images-secure-or-insecure[Using Secure or Insecure Connections]
+for more information.
+
+xref:limits.adoc#image-limits[limit]
+
+xref:using-wrong-certificate-authority[Using the Wrong Certificate Authority]
+or xref:using-insecure-connection-against-secured-registry[Using an Insecure
+Connection Against a Secured Registry].
+
+xref:../dev_guide/managing_images.adoc#tag-naming[Learn more about _istag_
+naming.]
+////
diff --git a/registry/accessing-the-registry.adoc b/registry/accessing-the-registry.adoc
index 5c417db46e..d3f39d95b3 100644
--- a/registry/accessing-the-registry.adoc
+++ b/registry/accessing-the-registry.adoc
@@ -1,4 +1,5 @@
-:context: accessing-the-registry.adoc
+:context: accessing-the-registry
+[id='accessing-the-registry']
 = Accessing the registry
 include::modules/common-attributes.adoc[]
 toc::[]
diff --git a/registry/securing-exposing-registry.adoc b/registry/securing-exposing-registry.adoc
index 11b6242ed8..a93348cb30 100644
--- a/registry/securing-exposing-registry.adoc
+++ b/registry/securing-exposing-registry.adoc
@@ -1,4 +1,5 @@
 :context: securing-exposing-registry
+[id='securing-exposing-registry']
 = Securing and exposing the registry
 include::modules/common-attributes.adoc[]
 toc::[]