diff --git a/keps/sig-storage/20180515-svcacct-token-volumes.md b/keps/sig-storage/20180515-svcacct-token-volumes.md
index 7dda4cc133d3..e58df1ec4995 100644
--- a/keps/sig-storage/20180515-svcacct-token-volumes.md
+++ b/keps/sig-storage/20180515-svcacct-token-volumes.md
@@ -4,16 +4,18 @@ authors:
   - "@smarterclayton"
   - "@liggitt"
   - "@mikedanese"
+	- "@zshihang"
 owning-sig: sig-storage
 participating-sigs:
   - sig-auth
 reviewers:
-  - TBD
+  - "@mikedanese"
+  - "@liggitt"
 approvers:
   - TBD
 editor: "@zshihang"
 creation-date: 2018-05-15
-last-updated: 2020-03-04
+last-updated: 2020-03-05
 status: implemented
 see-also:
   - "https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/svcacct-token-volume-source.md"
@@ -160,6 +162,14 @@ sources:
     audience: ca.istio.io
 ```
 
+### File Permission
+
+The owner of projected service account volume will be set to the user ID of the
+first container in the pod with mode 0600; if there are containers with
+different user IDs in the pod, `fsGroup` in the `PodSecurityContext` must be
+provided and the ownership will also be granted to the provided `fsGroup`.
+
+
 ### Alternatives
 
 1.  Instead of implementing a service account token volume projection, we could