Repository: kubernetes
Issue: Common approach for delegated pod admission & policy
Labels: kind/cleanup,kind/feature,sig/auth,priority/important-longterm,lifecycle/frozen

There are a number of features that apply policies to pods. However, this is challenging since pods are not typically created by users - they are typically created by a controller instantiating some pod template. Each policy addresses this in their own way:

- **PodSecurityPolicy** - policy is checked against the pods service account, in addition to the creating user. It is not intuitive to give the pod SA the permission to create itself. From a security standpoint, this is similar to namespace level, since we don't have special authorization for using a service account in a namespace.
- **NetworkPolicy** - a podselector determines the pods to apply to, but it's hard to guard or require use of the policy since pods can be created with any label (see next item). NetworkPolicy is namespaced, so a catch-all selector can require all pods in a namespace to comply.
- **ImagePolicy** - limits access to images in pod specs. No first-party story, delegates decisions to an external webhook. Review request includes image name (registry, name, tag, sha), pod annotations (matching prefix), and namespace.
- **LimitRanger, ResourceQuota** - limits resource requests, limits, and usage. Policies applied at namespace level (i.e. all pods in a namespace)
- **Toleration & NodeSelector restrictions** - namespace level, defined on the namespace object
- [Proposal for validated annotations](https://github.com/kubernetes/community/pull/1604) and [Proposal for restricting label access](https://docs.google.com/document/d/1Ql_Y-DRbvPCSA-o36CLOs3t4tQUoSvbQxtVEI4FCtEo/edit#heading=h.tx3ialsfu4bx) - Both face a similar problem of validating a pod.

Options for dealing with delegated policy application:

1. **Apply policy at the namespace level** - The most widely used approach right now, but we should standardize the API. This approach has the advantage that it is consistent with authorization (e.g. RBAC), where create permissions are granted at the namespace level. Disadvantages are that policies can't be applied more granularly in a namespace, and managing policy across namespaces needs to be handled.
2. **Apply policy on the pod's service account** - The approach PSP takes. This is counter intuitive, and doesn't really elevate security over the namespace approach, since service account access is not subdivided.
3. **Applied to requester, checked against PodTemplates** - Under this approach, the policy would be checked when a create ReplicaSet/Controller, Job, Deployment, DaemonSet, StatefulSet, etc. are created, matching the policy to the PodTemplate. To handle the delegation issue, controllers that create the pods according to the template are granted unrestricted access. This approach has an intuitive user experience, but a lot of problem including:
    - Dealing with CRDs & third party controllers is challenging
    - Large attack surface, if you can get control of a controller's credentials (particularly a problem for non-built in controllers)
    - Policy isn't checked against initializer values & mutating admission controllers that kick in at pod creation. Less of a problem if those apply to the podtemplates, but that has its own set of issues.
    - Not all policies can reasonable be applied at template creation time (e.g. ResourceQuota)
    - Updating a policy does not retroactively apply
4. **Delegated auth** - Same as above, but rather than granting unrestricted access to the controllers, grant them access to act as the user that initially created the template. This still faces a lot of the same problems as (3), but also introduces the challenge of determining if a Pod matches a template (which might be intractable, I can't come up with a good answer).
5. **??** - Suggestions wanted!

/kind feature
/sig auth
/priority important-longterm