christie-Dec-8-1

teps/0035-doc-policy-authentication-authorization-rbac.md

@@ -10,16 +10,19 @@ status: implementable
 # TEP-0035: Document Tekton position around Policy Authentication Authorization 
 
 <!-- toc -->
-- [TEP-0038: Document Tekton position around Policy Authentication Authorization](#tep-0035-document-tekton-position-around-policy-authentication-authorization)
+- [TEP-0035: Document Tekton position around Policy Authentication Authorization](#tep-0035-document-tekton-position-around-policy-authentication-authorization)
  - [Summary](#summary)
  - [Motivation](#motivation)
  - [Goals](#goals)
  - [Non-Goals](#non-goals)
  - [Requirements](#requirements)
  - [Proposal](#proposal)
+ - [Pod Security Policy (PSP)](#pod-security-policy-psp)
+ - [K8S RBAC](#k8s-rbac)
+ - [Validate ServiceAccounts with TaskRun / PipelineRun can reference ClusterTasks](#validate-serviceaccounts-with-taskrun--pipelinerun-can-reference-clustertasks)
+ - [Use of actual K8s RBAC](#use-of-actual-k8s-rbac)
+ - [Authentication for paths in Tekton that bypass K8s authentication](#authentication-for-paths-in-tekton-that-bypass-k8s-authentication)
  - [User Stories (optional)](#user-stories-optional)
- - [Story 1](#story-1)
- - [Story 2](#story-2)
  - [Notes/Constraints/Caveats (optional)](#notesconstraintscaveats-optional)
  - [Risks and Mitigations](#risks-and-mitigations)
  - [User Experience (optional)](#user-experience-optional)
@@ -28,8 +31,9 @@ status: implementable
  - [Test Plan](#test-plan)
  - [Drawbacks](#drawbacks)
  - [Alternatives](#alternatives)
+ - [If 'TaskRun' and 'PipelineRun' APIs had the 'requesting user' set on them, then I could do authorizations based on them](#if-taskrun-and-pipelinerun-apis-had-the-requesting-user-set-on-them-then-i-could-do-authorizations-based-on-them)
  - [Infrastructure Needed (optional)](#infrastructure-needed-optional)
- - [Upgrade &amp; Migration Strategy (optional)](#upgrade--migration-strategy-optional)
+ - [Upgrade & Migration Strategy (optional)](#upgrade--migration-strategy-optional)
 <!-- /toc -->
 
 ## Summary
@@ -85,7 +89,7 @@ inherently has the ability to integrate into key Kubernetes facilities around:
 - Extensibility
 - Security, policy, authentication, and authorization
 
-All those are a big advantage over pre-existing CI/CD systems, created before Containers and Kubernetes came en vouge, that have
+All those are a big advantage over pre-existing CI/CD systems, created before Containers and Kubernetes came en vogue, that have
 had to face challenges in trying to integrate their non-Kubernetes implementations of these system elements on
 a Kubernetes cluster. 
 
@@ -103,20 +107,28 @@ That documentation can be:
 - Parallel / polished versions of the such information in any Tekton related documentation beyond code repository 
 markdown files
 - References to third party implementations and associated libraries and catalogs of policy definitions that can solve 
-various concerns around security, policy, authentication, and authorization with respect to Tekton
- - There is some preliminary work already underway with the [OPA project](https://github.com/open-policy-agent/gatekeeper-library)
- directly and with [intermediaries](https://github.com/redhat-cop/rego-policies/tree/master/policy/tekton) working with that project.
- - Admittedly, there is a reasonable debate around whether or not to host say third party policy engine examples
+various concerns around security, policy, authentication, and authorization with respect to Tekton:
+
+ - There is some preliminary work already underway with the [OPA project](https://github.com/open-policy-agent/gatekeeper-library)
+ directly and with [intermediaries](https://github.com/redhat-cop/rego-policies/tree/master/policy/tekton) working with that project. 
+ - And even under the OPA umbrella, there are some styllistic choices are your disposal:
+
+ - Even with in Gatekeeper, there are [Rego policies that stand on their own](https://github.com/open-policy-agent/library/blob/master/docker/example.rego)
+ - As well as [Rego policies embedded in Kubernets Object YAML](https://github.com/open-policy-agent/gatekeeper-library/blob/master/library/pod-security-policy/proc-mount/template.yaml)
+ - And finally, [there are example Kubernetes policies as part of core OPA](https://github.com/open-policy-agent/library)
+
+ - Admittedly, there is a reasonable debate around whether we should host third party policy engine examples
  related to Tekton in our github organization. The rationale for not proposing such an approach:
- - It is easiest to be "policy engine agnostic" if you do not host any policy engine examples
- - Community member bandwidth around obtaining sufficient SME level skill for supporting policy examples; in addition
- to not adding policy engine like complexity in the Tekton code base, let's minimize the amount of time spent
- potentially debugging third party policy engine issues in the time community members have budgeted to work on
- Tekton 
- - Maximizing engagement with the various policy engine SMEs by interacting with them in their communities
- - Lastly, nothing prevents us in the future from pulling external catalog content into https://github.com/tektoncd
- as our ecosystem evolves and that content reaches some set of validation; in some sense, prudence / caution
- steers us to not doing it *initially*
+
+ - It is easiest to be "policy engine agnostic" if you do not host any policy engine examples
+ - Community member bandwidth around obtaining sufficient SME level skill for supporting policy examples; in addition
+ to not adding policy engine like complexity in the Tekton code base, let's minimize the amount of time spent
+ potentially debugging third party policy engine issues in the time community members have budgeted to work on
+ Tekton 
+ - Maximizing engagement with the various policy engine SMEs by interacting with them in their communities
+ - Lastly, nothing prevents us in the future from pulling external catalog content into https://github.com/tektoncd
+ as our ecosystem evolves and that content reaches some set of validation; in some sense, prudence / caution
+ steers us to not doing it *initially*
 
 Also note, any documentation in this space should always be considered "evolving" in the sense that the Kubernetes ecosystem
 continues to evolve in this space. As we learn of new upstream Kubernetes or Knative enhancements, or as new scenarios