Keep securitycontext fields simple in e2e

[piyush-garg]

This will make securitycontext fields to be simple and easy in e2e so that tests can be run on different platform like openshift where runasUser 65532 and 2000 etc can fail, here we are just checking the conversion of fields so simple configuration will also do the job

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

• Has Docs if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps
• Has Tests included if any functionality added or changed
• Follows the commit message standard
• Meets the Tekton contributor standards (including functionality, content, code)
• Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
• Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)
• Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes

allow e2e tests to run on openshift using securitycontext fields simple

[piyush-garg]

/kind misc

[piyush-garg]

/test check-pr-has-kind-label

[tekton-robot]

@piyush-garg: The specified target(s) for /test were not found.
The following commands are available to trigger required jobs:

• /test pull-tekton-pipeline-alpha-integration-tests
• /test pull-tekton-pipeline-beta-integration-tests
• /test pull-tekton-pipeline-build-tests
• /test pull-tekton-pipeline-integration-tests
• /test tekton-pipeline-unit-tests

The following commands are available to trigger optional jobs:

• /test pull-tekton-pipeline-go-coverage

Use /test all to run all jobs.

In response to this:

/test check-pr-has-kind-label

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vdemeester

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [vdemeester]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[lbernick]

Related: #3452 and #6515
I wonder if we can also use runAsNonRoot instead of runAsUser for the pipelinerun controller and pod init containers?

@piyush-garg I'm looking at https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html to figure out which securitycontext fields are and aren't accepted and it's a bit unclear; it seems like runAsUser needs to match any securityContextConstraints defined, which is an openshift concept? Do you know if any other security context fields cause trouble on openshift or just this one?

Also, a release note that might be a bit clearer could be "allow e2e tests to run on openshift"

[piyush-garg]

Related: #3452 and #6515 I wonder if we can also use runAsNonRoot instead of runAsUser for the pipelinerun controller and pod init containers?

@piyush-garg I'm looking at https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html to figure out which securitycontext fields are and aren't accepted and it's a bit unclear; it seems like runAsUser needs to match any securityContextConstraints defined, which is an openshift concept? Do you know if any other security context fields cause trouble on openshift or just this one?

Also, a release note that might be a bit clearer could be "allow e2e tests to run on openshift"

we have faced issues with runAsUser, runAsGroup and fsGroup, also sometimes with runAsRoot also

[vdemeester]

Related: #3452 and #6515 I wonder if we can also use runAsNonRoot instead of runAsUser for the pipelinerun controller and pod init containers?

So for pipelinerun controller, we are "patching" those with the operator (aka we are removing them, letting the random uid take over). I do not remember that we set some on init containers though, do we ?

@piyush-garg I'm looking at https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html to figure out which securitycontext fields are and aren't accepted and it's a bit unclear; it seems like runAsUser needs to match any securityContextConstraints defined, which is an openshift concept? Do you know if any other security context fields cause trouble on openshift or just this one?

Yes, and by default the "userid" set in a pod is randomly taken from a range that is assigned to a namespace. This makes any "explicit" runAsUser a slight problem (as usually they are set lower than the one radomly available).
(The link is on 3.11 which is very old though 🙃 but it still work similarly)

[lbernick]

@vdemeester we don't currently set security context for init containers but I was trying to add it in #6515

[piyush-garg]

/retest

[vdemeester]

@vdemeester we don't currently set security context for init containers but I was trying to add it in #6515

ah right 🙃

[piyush-garg]

/retest

[piyush-garg]

@lbernick Can you please take a look and merge this PR

[lbernick]

/lgtm

@piyush-garg can you please address the feedback on the release notes?

[piyush-garg]

/lgtm

@piyush-garg can you please address the feedback on the release notes?

done, updated the release notes. Thanks for merging.