postgres-operator icon indicating copy to clipboard operation
postgres-operator copied to clipboard

Add ability to annotate individual service accounts

Open gricey432 opened this issue 2 years ago • 5 comments

I'm running multiple postgres clusters all using s3 as the backup target. Following the principle of least access I'm generating a unique IAM role for each one. This role only allows access to the specific s3 bucket and prefix, as advised by pgbackrest.

AWS EKS recommends restricting which service accounts can assume each role using conditions in the trust relationship. E.g.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::<accid>:oidc-provider/oidc.eks.ap-southeast-2.amazonaws.com/id/<clusterid>"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "oidc.eks.ap-southeast-2.amazonaws.com/id/<clusterid>:sub": "system:serviceaccount:<namespace>:<saname>",
                    "oidc.eks.ap-southeast-2.amazonaws.com/id/<clusterid>:aud": "sts.amazonaws.com"
                }
            }
        }
    ]
}

The pgo docs say the service accounts are made automatically, but doesn't detail what they'll be called.

Running kubectl get sa -n postgres-operator I get:

NAME                            SECRETS   AGE
hippo-instance     1         12d
hippo-pgbackrest   1         12d
default                         1         12d
pgo                             1         12d
pgo-upgrade                     1         12d

Which of these need S3 access for backups to work? Are these names guaranteed to be consistent? Can I fix the names in the manifest?

Environment

Please provide the following details:

  • Platform: EKS
  • Platform Version: eks.2 1.23
  • PGO Image Tag: ubi8-14.5-5.2.0-0
  • Postgres Version 14
  • Storage: ebs s3

gricey432 avatar Oct 19 '22 00:10 gricey432

Hi @gricey432! Thanks for your questions.

In the above, it's hippo-instance that needs S3 access. And yes, these names are guaranteed to be consistent. The name of the instance service account is prefixed with the name of your PostgresCluster, which is hippo in this case.

tony-landreth avatar Oct 27 '22 14:10 tony-landreth

Thanks @tony-landreth !

In the docs example it says spec.metadata.annotations the correct place to be putting this role-arn.

This gives the annotation to everything made by pgo, which doesn't seem desirable.

Is there a way this annotation could be more directly targeted to just the hippo-instance service account so it's not leaking around on other resources?

Cheers :)

gricey432 avatar Oct 28 '22 01:10 gricey432

Hi @gricey432 ! Good question and totally understandable. We have plans to allow annotations on individual Service Accounts in a future PGO release.

tony-landreth avatar Oct 28 '22 16:10 tony-landreth

Hi, Is it on your roadmap already? Do you know in which PGO release can we expect this feature? Thanks in advance for response

gkolvo avatar Feb 23 '23 12:02 gkolvo

Also, it'd be great to be able to specify the service-account name. Otherwise, you need to ensure that the IAM role you create allows access to the specific name chosen by the operator as a service account name.

javiermas avatar Aug 14 '23 10:08 javiermas