Hello, Our organization manages EKS services accounts via CICD, and it doesn’t allow Flyte to create its own service accounts (five of them: flyte-pod-webhook, flyteadmin, datacatalog, flytepropeller, flytescheduler). And the iam role’s trust relationships created by CICD is like:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::[123...]:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/[xyz...]"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringLike": {
          "<http://oidc.eks.us-east-1.amazonaws.com/id/[xyz...]:sub|oidc.eks.us-east-1.amazonaws.com/id/[xyz...]:sub>": "system:serviceaccount:mlforge:flyte-microservice"
        }
      }
    }
  ]
}

Is this going to be an issue? 1. How do I modify the flyte helm charts to accommodate that? e.g. will this work (repeat for the other two services in the values.yaml file?

flytepropeller:
  serviceAccount:
    # -- If the service account is created by you, make this false
    create: false
    name: mlforge:flyte-microservice   <- this is the one and only existing service account for flyte in the cluster; notice the : in the name.

2. what about the service accounts that are defined in the helm templates (flyte-pod-webhook & flytescheduler)? what should the changes be like? Thank you!

With

helm template …

you could obtain the service account definitions without actually trying to create them. Then you could create them via CICD. In the helm chart you can turn of service account creation as you proposed here. You might also have to create the roles and rolebindings for the default service accounts used by the task pods “externally”, depending on your constraints. I don’t know about the service accounts of pod webhook and scheduler tbh but if you can find a way to prevent the helm chart from creating them, I imagine you can just create them via CICD as well.