Configure travis CI and OpenShift CI to support testing features with secrets

[GeekArthur]

/kind feature

Which functionality do you think we should add?

We need a mechanism to inject secrets into travis CI and OpenShift CI environment so that we can test features with secrets such as secure registry support feature #2893.

Rough design:
Travis CI: We can follow this instruction https://docs.travis-ci.com/user/deployment/pages/#setting-the-github-token to add secret to repository settings.
OpenShift CI: We will need to move to mutli-stage builds before we can inject custom secrets.

FYI: @amitkrout @mohammedzee1000

Why is this needed?

Test features with secrets.

[mohammedzee1000]

Note, when we do this, we need to bear in mind the effect it will have on non-ci testing. This includes local testing as well where the secret might not be injected.

Please ensure the said tests can be skipped if env cannot be set / document how users can provide their own tokens.
Note: Whatever the case, the tests should be compulsory in CI as we will inject the envs there.

[mohammedzee1000]

/area testing
/priority medium

[kadel]

Travis CI: We can follow this instruction https://docs.travis-ci.com/user/deployment/pages/#setting-the-github-token to add secret to repository settings.

This works only for PR that was opened from branch in the main do repo. It won't work for forks. This restriction is there for security. Otherwise, anyone who can open PR could extract secrets.

[kadel]

We need a mechanism to inject secrets into travis CI and OpenShift CI environment so that we can test features with secrets such as secure registry support feature.

You don't need secure secrets for testing. For testing, you can use some fake registry where it doesn't matter that secret gets leaked

[mohammedzee1000]

We need a mechanism to inject secrets into travis CI and OpenShift CI environment so that we can test features with secrets such as secure registry support feature.

You don't need secure secrets for testing. For testing, you can use some fake registry where it doesn't matter that secret gets leaked

+1 to that. we should avoid unnecessary complication if we can

In fact, in this case we can say have a token with read-only access on a test registry. That way it won't matter if a billion people can get it

[GeekArthur]

Travis CI: We can follow this instruction https://docs.travis-ci.com/user/deployment/pages/#setting-the-github-token to add secret to repository settings.

This works only for PR that was opened from branch in the main do repo. It won't work for forks. This restriction is there for security. Otherwise, anyone who can open PR could extract secrets.

Yes, that's a expected restriction for security.

[GeekArthur]

We need a mechanism to inject secrets into travis CI and OpenShift CI environment so that we can test features with secrets such as secure registry support feature.

You don't need secure secrets for testing. For testing, you can use some fake registry where it doesn't matter that secret gets leaked

+1 to that. we should avoid unnecessary complication if we can

In fact, in this case we can say have a token with read-only access on a test registry. That way it won't matter if a billion people can get it

Currently the registry is GitHub-hosted registry, given GitHub only supports user-scoped token instead of repo-scoped token, so I don't think the scope of GitHub token supports read-only access.

I find some resource from OpenShift: https://www.openshift.com/blog/private-git-repositories-part-3-personal-access-tokens

At this point in time, GitHub doesn't provide a way of setting the scope of a personal access token such that it has read-only access to repositories. Instead, one has to enable the repo scope which gives full control of private repositories.

You don't need secure secrets for testing. For testing, you can use some fake registry where it doesn't matter that secret gets leaked

Actually the current design of testing registry is fake registry, the purpose of adding the security mechanism is not for making the testing registry secure, it's for making all other repos/information under the same GitHub user (currently all registry related resource are under this GitHub user https://github.com/odo-devfiles) secure so that the public users won't use the token for testing to access all other repos/information under the same GitHub user given GitHub token only support user-scoped token so that we don't have a way to create a token only for the repo that hosts testing registry.

BUT, if we don't have a plan to create a private repo under GitHub user https://github.com/odo-devfiles in the future, then we don't need this security mechanism and we can expose the token to public.

Another benefit of adding the security mechanism is for future features with secrets, if we still have a way to mock the secure resource for the new feature then that would fine, but if we can't we still need to come back and do the configuration.

[GeekArthur]

We already discuss this issue in today's status meeting, we don't need to test the scenario for secure registry, so close this issue.