Add PSA Flag to Scorecard

[theishshah]

Add PSA Flag to Scorecard

[jmrodri]

/lgtm

[everettraven]

A nit/typo:

Suggested change

	podSecFlag := true
	if c.podSecurity == "resticted" {
	podSecFlag = true
	} else if c.podSecurity == "legacy" {
	podSecFlag = false
	}
	podSecFlag := true
	if c.podSecurity == "restricted" {
	podSecFlag = true
	} else if c.podSecurity == "legacy" {
	podSecFlag = false
	}

As an aside, since we are processing this as a boolean, would it be easier to just make this a boolean flag rather than a string flag? Maybe something like --enable-psa? This way we don't have to do any if statements like this where we are processing a string into a boolean.

[jmrodri]

Somehow I missed this. No it should not be treated as a boolean. It should match what we're doing in run bundle. #6062 we treat it as an enum to match what is in operator-framework/api.

[everettraven]

Would it be possible for the scorecard implementation to import and use the same logic that was created for operator-sdk run bundle?

I'm fine to leave this as is if we are happy with it, but it would be nice to be using the same tooling/logic in all places we want this kind of functionality rather than having slightly different methods for each implementation.

[jmrodri]

It might be possible, just seems weird. We would likely want to move the enum stuff out of run bundle into a common area so that it can be used by both sides: scorecard & run bundle.

[bcrochet]

In my testing, a bit more than this was necessary.

https://github.com/operator-framework/operator-sdk/pull/6181/files#diff-799876ec2e5aaa40d10a0e540a1cf58844df2b467fe803fac8956728bbefe6b9R73-R144

[jmrodri]

He's adding the Seccompprofile

	// SecurityContext: &corev1.PodSecurityContext{
	//     SeccompProfile: &corev1.SeccompProfile{
	//         Type: corev1.SeccompProfileTypeRuntimeDefault,
	//     },

That's what we ended up adding to the run bundle command. You shouldn't have to add the runuser to it.

[bcrochet]

When I was testing my patch, the 'scorecard-untar' init container needed the RunAsUser (the RunAsGroup may not be necessary, but I put it in there for completeness). This is needed because this container utilizes UBI directly, and UBI does not specify a user. Hence, the untar will not run. Here is the error message:

  Warning  Failed     4s (x2 over 4s)  kubelet            Error: container has runAsNonRoot and image will run as root (pod: "scorecard-test-tw6p_default(dba24b81-7d41-4941-9b4f-946e2a15a079)", container: scorecard-untar)

This is from running kubectl describe pod scorecard-test-xxxx with this patch. That's why the timeout is occurring in the e2e test. This is consistent with what I saw when testing before I put in the RunAsUser.

[everettraven]

Maybe we should consider creating and pushing a custom image that will run as a non-root user by default?

[jmrodri]

@bcrochet I discussed with @everettraven and you are correct with the RunUser. The reason I didn't have to do it with run bundle was the index images have the proper userids. So +1 to adding your changes to this PR.

[bcrochet]

Maybe we should consider creating and pushing a custom image that will run as a non-root user by default?

My first thought was "why bother?" but then I had the thought that it might not be a bad idea to do that, and have it be based on ubi(8|9):latest so that it is kept up-to-date on every release of operator-sdk.

[everettraven]

My first thought was "why bother?" but then I had the thought that it might not be a bad idea to do that, and have it be based on ubi(8|9):latest so that it is kept up-to-date on every release of operator-sdk.

My only reason for suggesting this was because I believe that there is a problem when setting RunAsUser on OpenShift >= 4.11.

There is this note in the sample pod security manifest in the Operator SDK Pod Security Standards docs:

# WARNING: Ensure that the image used defines an UserID in the Dockerfile
# otherwise the Pod will not run and will fail with `container has runAsNonRoot and image has non-numeric user`.
# If you want your workloads admitted in namespaces enforced with the restricted mode in OpenShift/OKD vendors
# then, you MUST ensure that the Dockerfile defines a User ID OR you MUST leave the `RunAsNonRoot` and
# RunAsUser fields empty.

Creating the custom container image that can be used by default would allow the default logic to always work without specifying RunAsUser which, as far as I understand, should make the default logic work on any cluster.

[bcrochet]

The "why bother?" was more about just one more asset to have to track. I'm totally on board with doing it though. I think it makes a lot of sense once I took a step back and thought about it.

[everettraven]

@theishshah was there ever any decision on the direction to go in regards to creating a new container image for scorecard that will run as a non root user within the container?

[jmrodri]

@theishshah @everettraven why is this PR still here? This should've been done a while ago. What's holding it up?

[everettraven]

@theishshah @everettraven why is this PR still here? This should've been done a while ago. What's holding it up?

Honestly not sure. I'm on vacation for the next 2 weeks but if this PR is still hanging out when I get back I'll try to move this along.

[laxmikantbpandhare]

These changes look good to me. One thing I think will cause an error in CI is that we probably need to run make generate to update the documentation on the scorecard cmd flags (i could be wrong).

/lgtm

@everettraven - Yes, I updated the website content for the ScoreCard.

[everettraven]

/lgtm

[oceanc80]

Closes #5939

[jmrodri]

👏🏽 👏🏽 👏🏽