operator-framework / operator-lifecycle-manager

A management framework for extending Kubernetes with Operators
https://olm.operatorframework.io
Apache License 2.0
1.71k stars 544 forks source link

[RFE] IAM-linked Service Accounts #1931

Open EronWright opened 3 years ago

EronWright commented 3 years ago

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:

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::<AWS_ACCOUNT_ID>:role/<IAM_ROLE_NAME>

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 the config section in Subscription 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-linked ServiceAccount and apply annotations as necessary before installing any operators. OLM would use the service account (applying secondary owner references, if needed).

jeloba commented 3 years ago

I think #1881 could provide the "alternative solution."

EronWright commented 3 years ago

@jeloba I respectfully disagree that #1881 addresses the issue. The alternate solution would require that OLM preserve annotations on existing service accounts, at minimum.

jeloba commented 3 years ago

:disappointed: You are right, didn't look into the code and expected them to improve SA handling/ownership during both creation and deletion...