gistfile1.txt

Kubernetes - ACL Model
Proposed PR:
https://github.com/GoogleCloudPlatform/kubernetes/pull/891
Proposal Summary:
0...N User Account objects
    Each User Account object may have a default Project
0...N Project objects
Each Project contains
  0...N Policy objects
      Each policy object has:
          Name
          PolicyType (Allow / Deny)
          Subject (which is a label selector)
          Verb (HTTP Method)
          Object (HTTP Path based, exact match, prefix match, or label selector match)          
  0...N Pod, Service, ReplicationController objects
Some discussion on ability to template Policy objects to let you stamp out common versions on project creation for particular scenarios.
Proposal Feedback:
1.  Is there a use-case for Policy objects not scoped to a project?  Examples:

    control access to a minion via Policy?  Could a minion be associated with a project to limit scheduling?

    global policy allowing access to everything to admin users

    global policy giving service accounts access for automated tasks (auditing?)

2.  Is HTTP Proxy the preferred method of enforcing ACL?
3.  Is the Policy object making the simple scenario more complex than needed?
4.  Is a Kubernetes Provider required to support all Policy types?
5.  Delegation is implied via more narrowly tailored policies, need more examples.
6.  Are label selectors enough to support use case?
7.  Desire to control who has restart capability on a pod.
8.  Can we define a Policy Template as a global resource?  Can we associate a Policy Template(s) with a Project Template to make initial setup easier?
9.  A policy object should have timestamps.
Typical scenario:
I have a global administrator for my OpenShift deployment that needs to access each Project.
Each project is managed by a team where each member may have particular roles with varying rights.
System view:
We have a Policy object that denotes global admin access added to each Project.
Policy{
    project: "the project", 
    name:"openshift_admin",
    prefix: "/", 
    s:"group=openshift_admin"
    v: "ANY"
    o: {
        prefix: "/"
    }
}
Option 1:
For each unique role, we would need to have a Policy object, but in this case our Policy subject would need to use an OR in the label selector that enumerated each person or group.  This could get awkward to manage.  If a policy object has timestamps, harder to reconcile when a person was added or removed from the project from this model.
Option 2:
For each person or group, we have a dedicated Policy object.  Simpler to enumerate, more resources to compare potentially.  Easier to audit when a person was added or removed from data model.
Issues:
There is a note that "Policy object is immutable, and is statically populated by admin"
It sounds like there is a need for a policy template, but don't you need to edit a policy in order to modify subjects to grow access?