Open EronWright opened 3 years ago
I think #1881 could provide the "alternative solution."
@jeloba I respectfully disagree that #1881 addresses the issue. The alternate solution would require that OLM preserve annotations on existing service accounts, at minimum.
:disappointed: You are right, didn't look into the code and expected them to improve SA handling/ownership during both creation and deletion...
Feature Request
Is your feature request related to a problem? Please describe. In certain clouds, is possible to associate a Kubernetes Service Account (KSA) with an IAM Role/Account. This allows the pod to assume the IAM role automatically, e.g. to interact with a cloud service such as S3 or Stackdriver. In Google Kubernetes Engine (GKE), this is referred to as Workload Identity. In Amazon EKS, it is IAM roles for service accounts.
Both options rely on the use of an annotation on the KSA. For example:
The purpose of this issue is to add support into OLM for service accounts with IAM annotations.
Describe the solution you'd like I would like a solution which allows the IAM role/account to be configurable, since the role/account typically varies across environments. Observe the variable
AWS_ACCOUNT_ID
in the above example. One solution might be to extend theconfig
section inSubscription
type (ref), to accept annotations for the service accounts that are defined in the CSV.Note that additional configuration steps are typically needed on the Cloud IAM side, to set a policy which allows the KSA to assume the IAM role in question. These steps generally assume that the KSA has a well-known namespace + name.
Alternative Solution A simple alternative would be to support the use of pre-existing
ServiceAccount
objects. An external system would create an IAM-linkedServiceAccount
and apply annotations as necessary before installing any operators. OLM would use the service account (applying secondary owner references, if needed).