Specify verbs in admission controller doc

content/en/docs/reference/access-authn-authz/admission-controllers.md

@@ -32,6 +32,8 @@ which are configured in the API.
 Admission controllers may be "validating", "mutating", or both. Mutating
 controllers may modify the objects they admit; validating controllers may not.
 
+Admission controllers limit requests to create, delete, modify or connect to (proxy). They do not support read requests.
+
 The admission control process proceeds in two phases. In the first phase,
 mutating admission controllers are run. In the second phase, validating
 admission controllers are run. Note again that some of the controllers are

content/en/docs/reference/access-authn-authz/controlling-access.md

@@ -63,9 +63,9 @@ users in its object store.
 
 ## Authorization
 
-After the request is authenticated as coming from a specific user, the request must be authorized. This is shown as step **2** in the diagram. 
+After the request is authenticated as coming from a specific user, the request must be authorized. This is shown as step **2** in the diagram.
 
-A request must include the username of the requester, the requested action, and the object affected by the action. The request is authorized if an existing policy declares that the user has permissions to complete the requested action. 
+A request must include the username of the requester, the requested action, and the object affected by the action. The request is authorized if an existing policy declares that the user has permissions to complete the requested action.
 
 For example, if Bob has the policy below, then he can read pods only in the namespace `projectCaribou`:
 
@@ -97,7 +97,7 @@ If Bob makes the following request, the request is authorized because he is allo
   }
 }
 ```
-If Bob makes a request to write (`create` or `update`) to the objects in the `projectCaribou` namespace, his authorization is denied. If Bob makes a request to read (`get`) objects in a different namespace such as `projectFish`, then his authorization is denied. 
+If Bob makes a request to write (`create` or `update`) to the objects in the `projectCaribou` namespace, his authorization is denied. If Bob makes a request to read (`get`) objects in a different namespace such as `projectFish`, then his authorization is denied.
 
 Kubernetes authorization requires that you use common REST attributes to interact with existing organization-wide or cloud-provider-wide access control systems. It is important to use REST formatting because these control systems might interact with other APIs besides the Kubernetes API.
 
@@ -110,10 +110,11 @@ To learn more about Kubernetes authorization, including details about creating p
 
 Admission Control Modules are software modules that can modify or reject requests.
 In addition to the attributes available to Authorization Modules, Admission
-Control Modules can access the contents of the object that is being created or updated.
-They act on objects being created, deleted, updated or connected (proxy), but not reads.
+Control Modules can access the contents of the object that is being created or modified.
 
-Multiple admission controllers can be configured.  Each is called in order.
+Admission controllers act on requests that create, modify, delete, or connect to (proxy) an object.
+Admission controllers do not act on requests that merely read objects.
+When multiple admission controllers are configured, they are called in order.
 
 This is shown as step **3** in the diagram.