postgres-operator
postgres-operator copied to clipboard
Add ability to annotate individual service accounts
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
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.
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 :)
Hi @gricey432 ! Good question and totally understandable. We have plans to allow annotations on individual Service Accounts in a future PGO release.
Hi, Is it on your roadmap already? Do you know in which PGO release can we expect this feature? Thanks in advance for response
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.