3scale/3scale-operator

Allow use of IRSA for s3 bucket configurations

Opened this issue · 5 comments

Instead of providing credentials for the s3 bucket, we would like to take advantage of IRSA with OpenShift
https://docs.openshift.com/rosa/rosa_architecture/rosa-sts-about-iam-resources.html

long-lived aws credentials are not desired.

eguzki commented

Thanks for the request.

Is it about the STS authentication for S3 as defined in 3scale operator doc about s3 with STS and implemented in #792 ? Jira issue https://issues.redhat.com/browse/THREESCALE-8772

It might be possible to point the AWS_WEB_IDENTITY_TOKEN_FILE secret value to the resulting token provisioned with IRSA.

However, i still think the APIManager config can support IRSA in a more direct fashion. For example:

    fileStorage:
      simpleStorageService:
        irsa:
          enabled: true
          audience: sts.amazonaws.com
          roleArn: arn:aws:iam::....

I would then expect the operator to add the needed annotations on the appropriate ServiceAccounts to enable IRSA.

eguzki commented

Could you elaborate more? I am not familiar with IRSA (cannot find it in the doc provided). Also I cannot read anything about adding annotations to a serviceaccount objects.

https://cloud.redhat.com/blog/running-pods-in-openshift-with-aws-iam-roles-for-service-accounts-aka-irsa

The TLDR:

  • Create a Role/Trust Relationship in AWS. OpenShift ROSA automatically creates the Identity Providers for you per OpenShift Cluster in AWS.
  • The ServiceAccount the 3scale PODs are using (that need s3 access), will then need the correct IRSA annotations, referencing the role ARN that was created in AWS. e.g.
    eks.amazonaws.com/audience: sts.amazonaws.com
    eks.amazonaws.com/role-arn: "arn:aws:iam::...
    This is where defining the audience/roleArn in the APIManager definition for IRSA (example) i think would make IRSA very accessible.

EPIC here dealing with improving STS support. Still in planning