Feature Overview

OpenShift users on cloud providers leveraging short-lived token authentication with their cluster and OLM-managed operators are guided through updates of such operators, in case where their IAM permission requirements change. When that happens, the users get clear signals and instructions what they need to do.

Goals

OpenShift and OLMs update safety guarantees extend to operators that require changes to their short-lived token authentication requirements. In particular, when new IAM permissions are needed, we prevent the customer from unexpected regressions and outages, thus increasing uptime and customer satisfaction.

Requirements:

• OLM-managed operators, which support cloud provider authentication via short-lived tokens (e.g. AWS STS, Azure Identity, GCP WIF) should be able to increase their IAM permissions requirements between major or minor version changes of the operator or the operand
• OpenShift admins, managing the update of this operator become aware of the fact either before or immediately after the upgrade took place
• OpenShift admins, in a situation where IAM permissions of an OLM-managed operator with support for short-lived token authentication, have or will increase, gets clear instructions and a standardized workflow in which they discover the delta and what actions need to be carried out to adjust the IAM permissions
• Operators, which are in a state where permission requirements have increased, but have not seen their permissions adjusted, need to report a degraded state, so that a clear call to action is presented to the administrator
• all of the above requirements needs to be covered by the cluster's APIs and the OpenShift Console

Use Cases:

• an OLM-managed operator's IAM permission requirements change as part of an updated, immediately after the upgrade the operator reports a degraded state due to partially insufficient permissions
• after adjusting permissions by the cluster's or cloud provider account admin, either the OpenShift admin has to acknowledge that the permissions have been updated or the operator can automatically detect that with cloud provider permission introspection

Questions to Answer:

• how should the case of decreasing permission requirements be handled?

Out of Scope

• automatic remediation or adjustments of permission requirements by the cluster or other mechanisms

Background

IAM permissions requirements of an operator that interacts with cloud provider APIs can increase as the operator matures and has more features. They can also decrease, as the result of streamlining permission requirements following least privileged principle or as a result of splitting up functionality into separate operator projects. Without adjusting the permissions, especially in the case of an increase in requirements, the operator will very likely not be able to carry out user requests and might even cease to reconcile existing workloads. Since updates can happen automatically, we need a way to raise the attention of the cluster's admin to such a situation.

Anecdotal evidence suggest that in practice permission increases are somewhat rare and often permission scopes are too broad and should be tightened.

Customer Considerations

Customers expect that increased permission requirements are handled as part of the update flow.

Documentation Considerations

The operator in question needs to clearly document what actions need to be taken to adjust the permission scope.