proposal for projected service account volume file permission handling

keps/sig-storage/20180515-svcacct-token-volumes.md

@@ -4,6 +4,7 @@ authors:
   - "@smarterclayton"
   - "@liggitt"
   - "@mikedanese"
+  - "@zshihang"
 owning-sig: sig-storage
 participating-sigs:
   - sig-auth
@@ -29,7 +30,9 @@ see-also:
 - [Motivation](#motivation)
 - [Proposal](#proposal)
   - [Token Volume Projection](#token-volume-projection)
-  - [Alternatives](#alternatives)
+  - [File Permission](#file-permission)
+    - [Alternatives:](#alternatives)
+  - [Alternatives](#alternatives-1)
 - [Graduation Criteria](#graduation-criteria)
 <!-- /toc -->
 
@@ -159,6 +162,40 @@ sources:
     audience: ca.istio.io
 ```
 
+### File Permission
+
+
+1. If there is only one UserID (non-root) shared by all the containers in a pod,
+set the owner of projected service account volume to the UserID and mode to 600.
+2. Otherwise, set the owners to be the UserID of the first container in the pod
+and the group either specified by `fsGroup` in the `PodSecurityContext` or
+unused GroupID and set the mode to 0640.
+
+UserID can be obtained by the following three ways:
+1. `runAsUser` in `SecurityContext`
+2. fetch UserID from image status
+3. 0 by default
+
+GroupID can be obtained by the following three ways:
+1. `fsGroup` in `SecurityContext`
+2. set a well-known GroupID (users can easily change it by setting `fsGroup`),
+or generate a random GroupID from set {GID_MIN ~ GID_MAX - used GroupIDs
+(`runAsGroup`, `supplementalGroups`, ..., etc.)}
+3. 0 by default
+
+we can also enforce the provisioning of UserID and GroupID in `SecurityContext`
+to minimize the changes in kubelet.
+
+#### Alternatives:
+1. same as the proposal except for creating a different volume for a different
+user ID instead of setting GroupID ownership.
+    + projected service account token is a pod level resource
+    + scalability issue. # of volumes = # of user IDs.
+2. use fsGroup and set mode to 0640
+    + not as fine-grained as UID.
+3. world read permission 0644 which is the same as the mode of secret
+    + security compromise
+
 ### Alternatives
 
 1.  Instead of implementing a service account token volume projection, we could