Potential security risk using Openshift Connection Service

[DamianBacalov]

When using the Task "Execute OC command" with Openshift Connection Service, the module uses the kubeconfig placed in the home folder. This is a security risk for several reasons:
. The information is not deleted when the execution ends. This means that the kubeconfig has all the service accounts credentials on it and anyone can create a pipeline to see it.
. If two pipelines starts in parallel the second pipeline overwrites the information causing the first one will be using a wrong connection
. In the previous scenario, one pipeline could starts deploying objects in one cluster and ends in another cluster

The solution could be to use a kubeconfig placed in the same cloned folder (which is exclusive for the execution).

I think the problem is in the file "src/oc-auth.ts" line 135. I'm attaching a screenshot.

Thanks!
D.

[lstocchi]

Hi @DamianBacalov,
sorry for the slow response but there is no active maintainer afaik.

It looks to me that you would like to update the path to $(System.DefaultWorkingDirectory)/.kube/config?
Could you update the HOME env to System.DefaultWorkingDirectory when executing the oc-cmd task or is there any drawback in your pipeline? Or have you tried using the runtime config path? You can specify where the kubeconfig you want to use is located.

[DamianBacalov]

As I said, is not that I want to do something special. As it works right now, is a security risk.

I've compared it with the same module in Github Actions. In Github Actions, when you log in to Openshift, the kubeconfig is placed inside the cloned folder which then will be deleted. So there is no possibility of override another parallel execution.
In Azure Devops Pipelines, it uses a kubeconfig outside the cloned folder and it's location is shared with other executions.

I could even execute a pipeline with an oc command without login because all previous pipelines executions have already done the login using a "shared kubeconfig" which is not deleted when the execution ends.

To use a shared kubeconfig that is not deleted after the execution is a serious security risk.