In RHOSP 1.4 (GA) release, we used `anyuid` scc bound to `pipeline` sa, the sevice account created by the operator in all namespace to be used as the default sa.

We decied not to release 1.4 with `restricted` scc and continue with `anyuid` scc because of this issue: s2i-* cluster tasks broken with 1.4.0 (nightly builds)

Details (related discussions):

• the pipeline succeeds :green_jenkins_circle: with anyuid and fails with with restricted

from what OpenShift docs, even if we add linux capabilities (eg: setuid, setgid) in the task manifest, it will be validated against scc. so if the scc is restricted it might not give us what we want.

so our options right now:
1. revert back to anyuid scc for pipeline serviceaccount
    - quick and immediate
    - but we will have to give up on our plan to move to restricted scc so that our task pods run with restricted scc (like the default scc for a pod)

2. provide a custom restricted "like" scc (everything set exactly like restricted but plus the capabilities we want in addition.
    2.1 we will create our own scc
    2.2 pipeline sa will be bound to that
    2.3 then we can ask for the capabilities in task spec.
this might help us go past the current error we are facing.

Option 2 is hard to estimate correctly at present.

You can provide the ability to request additional capabilities in the pod specification which will be validated against an SCC.
[https://docs.openshift.com/container-platform/3.6/admin_guide/manage_scc.html#provide-additional-capabilities
]
Requirements

Requirements

• define a "smooth" way to move to the use of `restricted` scc
• create a custom scc if required which is similar to `restricted` scc but add neccessary modifications needed for tekton taskruns. (refer linked bug)

Acceptance Criteria

• a "restricted like" scc is bound to the default "pipeline" sa instead of `anyuid` scc
• proper clean up of previous clusterroles, rolebinding (pipeline-anyuid) is handled properly