Summary

The workflow-role lacks granularity in its privileges, giving permissions to workflowtasksets and workflowartifactgctasks to all workflow Pods, when only certain types of Pods created by the Controller require these privileges.

The impact is minimal, as an attack could only affect status reporting for certain types of Pods and templates.

This was resolved by #3048

Details

Two sets of permissions are only needed for certain types of Pods created by the Controller:

workflowtasksets and workflowartifactgctasks

• Only the Agent, which currently only runs for HTTP and Plugin Templates, uses workflowtasksets
• Only ArtifactGC Pods, which can be optionally run to garbage collect artifacts, use workflowartifactgctasks

These two should ideally be split into their own roles, as they are upstream. This requires a UX change to the Charts, however.

Impact

The impact of these two is quite minimal, as they only affect status reporting and only for ArtifactGC Pods and HTTP and Plugin templates. So that would only have a mild integrity impact, and that impact already exists upstream for properly privileged roles as well, which is more a limitation of k8s RBAC (in practice, it is effectively impossible to limit to resourceNames in this case as they are generated, dynamic names, and then each generated Pod would need custom resourceNames, i.e. dynamically generated RBAC).