Remove restricted Ansible documentation

This documentation is no longer relevant as we remove the restricted
Ansible modules.  Later commits will remove the testing and
implementation.  This commit is first due to the autodoc reference.

Change-Id: I272c9761db6beb846971ea2659b1d0a7c72b3f1c

doc/source/config/job.rst

@@ -375,11 +375,10 @@ Here is an example of two job definitions:
 
       If a job has an empty (or no) :ref:`nodeset` definition, it will
       still run and is able to perform limited actions within the Zuul
-      executor sandbox (e.g. copying files or triggering APIs).  Note
-      so-called "executor-only" jobs run with an empty inventory, and
-      hence Ansible's *implicit localhost*.  This means an
-      executor-only playbook must be written to match ``localhost``
-      directly; i.e.
+      executor sandbox.  Note so-called "executor-only" jobs run with
+      an empty inventory, and hence Ansible's *implicit localhost*.
+      This means an executor-only playbook must be written to match
+      ``localhost`` directly; i.e.
 
       .. code-block:: yaml
 

doc/source/configuration.rst

@@ -390,39 +390,14 @@ playbook is in a config project, the executor runs the playbook in the
 *trusted* execution context, otherwise, it is run in the *untrusted*
 execution context.
 
-Both execution contexts use `bubblewrap`_ [#nullwrap]_ to create a namespace to
+Both execution contexts use `bubblewrap`_ to create a namespace to
 ensure that playbook executions are isolated and are unable to access
 files outside of a restricted environment.  The administrator may
 configure additional local directories on the executor to be made
 available to the restricted environment.
 
-The trusted execution context has access to all Ansible features,
-including the ability to load custom Ansible modules.  Needless to
-say, extra scrutiny should be given to code that runs in a trusted
-context as it could be used to compromise other jobs running on the
-executor, or the executor itself, especially if the administrator has
-granted additional access through bubblewrap, or a method of escaping
-the restricted environment created by bubblewrap is found.
-
-Playbooks run in the untrusted execution context are not permitted to
-load additional Ansible modules or access files outside of the
-restricted environment prepared for them by the executor.  In addition
-to the bubblewrap environment applied to both execution contexts, in
-the untrusted context some standard Ansible modules are replaced with
-versions which prohibit some actions, including attempts to access
-files outside of the restricted execution context.  These redundant
-protections are made as part of a defense-in-depth strategy.
-
 .. _bubblewrap: https://github.com/projectatomic/bubblewrap
 
-.. _zuul-discuss: http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-discuss
-
-.. [#nullwrap] `bubblewrap` is integral to securely operating Zuul.
-      If it is difficult for you to use it in your environment, we
-      encourage you to let us know via the `zuul-discuss`_ mailing
-      list.
-
-
 Configuration
 ~~~~~~~~~~~~~
 

doc/source/developer/ansible.rst

@@ -2,29 +2,7 @@ Ansible Integration
 ===================
 
 Zuul contains Ansible modules and plugins to control the execution of Ansible
-Job content. These break down into two basic categories.
-
-* Restricted Execution on Executors
-* Build Log Support
-
-Restricted Execution
---------------------
-
-Zuul runs ``ansible-playbook`` on executors to run job content on nodes. While
-the intent is that content is run on the remote nodes, Ansible is a flexible
-system that allows delegating actions to ``localhost``, and also reading and
-writing files. These actions can be desirable and necessary for actions such
-as fetching log files or build artifacts, but could also be used as a vector
-to attack the executor.
-
-For that reason Zuul implements a set of Ansible action plugins and lookup
-plugins that override and intercept task execution during untrusted playbook
-execution to ensure local actions are not executed or that for operations that
-are desirable to allow locally that they only interact with files in the zuul
-work directory.
-
-.. autoclass:: zuul.ansible.base.action.normal.ActionModule
-   :members:
+Job content.
 
 Build Log Support
 -----------------

doc/source/glossary.rst

@@ -357,23 +357,14 @@ Glossary
    trusted execution context
 
       Playbooks defined in a :term:`config-project` run in the
-      *trusted* execution context.  The trusted execution context has
-      access to all Ansible features, including the ability to load
-      custom Ansible modules.
+      *trusted* execution context.  The trusted execution context may
+      have access to extra directories within the bubblewrap container
+      if the operator has configured these.
 
    untrusted execution context
 
       Playbooks defined in an :term:`untrusted-project` run in the
-      *untrusted* execution context.  Playbooks run in the untrusted
-      execution context are not permitted to load additional Ansible
-      modules or access files outside of the restricted environment
-      prepared for them by the executor.  In addition to the
-      bubblewrap environment applied to both execution contexts, in
-      the untrusted context some standard Ansible modules are replaced
-      with versions which prohibit some actions, including attempts to
-      access files outside of the restricted execution context.  These
-      redundant protections are made as part of a defense-in-depth
-      strategy.
+      *untrusted* execution context.
 
    untrusted-project
 

doc/source/job-content.rst

@@ -1093,7 +1093,7 @@ For example:
           registry_ip_address: "{{ hostvars[groups.all[0]].ansible_host }}"
 
 Skipping retries
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~
 
 It's possible to skip the retry caused by a failure in ``pre-run``
 by setting **zuul.retry** to ``false``.