Comments 2

contributors/design-proposals/kubelet-authorizer.md

@@ -24,12 +24,13 @@ This document proposes limiting a kubelet's API access using a new node authoriz
   * Authorizes requests from nodes using a fixed policy identical to the default RBAC `system:node` cluster role
   * Further restricts secret and configmap access to only allow reading objects referenced by pods bound to the node making the request
 * Node admission
-  * Limits nodes to only be able to mutate their own Node API object
-  * Limits nodes to only be able to mutate pods bound to themselves
-  * Limits nodes to only be able to create mirror pods
-  * Prevents creating mirror pods that reference API objects (secrets, configmaps, persistent volume claims)
-  * Prevents creating mirror pods that are not bound to nodes
-  * Prevents removing mirror pod annotations
+  * Limit nodes to only be able to mutate their own Node API object
+  * Limit nodes to only be able to create mirror pods bound to themselves
+  * Limit nodes to only be able to mutate mirror pods bound to themselves
+  * Limit nodes to not be able to create mirror pods that reference API objects (secrets, configmaps, service accounts, persistent volume claims)
+* Additional API validation
+  * Reject mirror pods that are not bound to a node
+  * Reject pod updates that remove mirror pod annotations
 
 ## Alternatives considered
 
@@ -84,22 +85,20 @@ A new node authorizer will be inserted into the authorization chain:
 * User-configured authorizers... (e.g. ABAC, RBAC, Webhook)
 
 The node authorizer is responsible for ensuring:
-* The request is made by a node (`IdentifyNode()` returns isNode=true)
-* The request is allowed by the rules contained in the default `system:node` cluster role
-
-Requests that do not meet those conditions are forbidden by this authorizer.
-Subsequent authorizers in the chain can run and choose to allow the request.
-
-Requests from identifiable nodes (`IdentifyNode()` returns nodeName != "") for secrets and configmaps are further restricted:
-* Requests for secrets are limited to `get`, and the requested secret must be related to the requesting node by one of the following relationships:
-  * node -> pod -> secret
-  * node -> pod -> pvc -> pv -> secret
-  * node -> pod -> pvc -> storageclass -> secret
-* Requests for configmaps are limited to `get`, and the requested configmap must be related to the requesting node by one of the following relationships:
-  * node -> pod -> configmap
-
-Requests that do not meet those conditions are forbidden by this authorizer.
-Subsequent authorizers in the chain can run and choose to allow the request.
+1. If a request is not from a node (`IdentifyNode()` returns isNode=false), reject
+2. If a request is not allowed by the rules in the default `system:node` cluster rule, reject
+3. If a specific node cannot be identified (`IdentifyNode()` returns nodeName=""), allow (this lets nodes that don't use node-specific identities continue to work with the broad authorization rules in step 2)
+4. If a request is for a secret, configmap, persistent volume or persistent volume claim, reject unless the verb is `get`, and the requested object is related to the requesting node:
+
+    * node -> pod
+    * node -> pod -> secret
+    * node -> pod -> configmap
+    * node -> pod -> pvc
+    * node -> pod -> pvc -> pv
+    * node -> pod -> pvc -> pv -> secret
+5. For other resources, allow
+
+Subsequent authorizers in the chain can run and choose to allow requests rejected by the node authorizer.
 
 ## Node admission
 
@@ -111,22 +110,21 @@ For requests made by identifiable nodes:
   * Limits `create` of pod resources:
     * only allow pods with mirror pod annotations
     * only allow pods with nodeName set to the node making the API request
-  * Limits `update`,`delete` of node and nodes/status resources:
-    * only allow modifying the node object corresponding to the node making the API request
-  * Limits `update`,`delete` of pod and pod/status resources:
-    * only allow modifying pods with nodeName set to the node making the API request (requires fetching the pod on delete)
-
-For requests made by any user:
-  * Limits `create` of pod resources with mirror pod annotations:
-    * Must specify a nodeName
-    * Must not reference any secrets, serviceaccounts, configmaps, or persistentvolumeclaims
-  * Limits `update` of pod resources with mirror pod annotations:
-    * Must not modify the mirror pod annotation
-    * Must not modify the nodeName
+    * do not allow pods that reference any API objects (secrets, serviceaccounts, configmaps, or persistentvolumeclaims)
+  * Limits `update` of node and nodes/status resources:
+    * only allow updating the node object corresponding to the node making the API request
+  * Limits `update` of pods/status resources:
+    * only allow reporting status for pods with nodeName set to the node making the API request
+  * Limits `delete` of node resources:
+    * only allow deleting the node object corresponding to the node making the API request
+  * Limits `delete` of pod resources:
+    * only allow deleting pods with nodeName set to the node making the API request
 
 ## API Changes
 
-None
+Change Pod validation for mirror pods:
+  * Reject `create` of pod resources with mirror pod annotations that do not specify a nodeName
+  * Reject `update` of pod resources with mirror pod annotations that modify or remove the mirror pod annotation
 
 ## RBAC Changes