@kevin another batch of permissions needed, now with exposing the services via loabalancers:
fedora-ci-eks
AccessDenied: User: arn:aws:sts::125523088429:assumed-role/fedora-ci-eks/1588887618931045869 is not authorized to perform: ec2:DescribeAccountAttributes
Currently we see denials like
User: arn:aws:sts::125523088429:assumed-role/aws-fedora-ci/mvadkert is not authorized to perform: elasticloadbalancing:DescribeInstanceHealth arn:aws:sts::125523088429:assumed-role/aws-fedora-ci/mvadkert is not authorized to perform: elasticloadbalancing:DescribeTags
Metadata Update from @mohanboddu: - Issue priority set to: Waiting on Assignee (was: Needs Review) - Issue tagged with: groomed, medium-gain, medium-trouble
@kevin kindly pinging, thanks
a) this is a Saturday, you should not expect and answer and I actually find this a little rude to do.
b) cf https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/thread/27U6YT73556KYW2RIFJO6J2HYMYVP22U/
@pingou
a) sorry I was not expecting any answer till the next working day or anytime it suits, did not expect it could be taken as rude, I will try to avoid such queries next time outside working hours
b) thanks, I guess that means this will be delayed, no problem at all, I will first try to check announce list next time
Have a nice weekend
Thanks for your understanding
@kevin This issue could be resolved by copying the permissions that were used in the following ticket https://pagure.io/fedora-infrastructure/issue/8958
@mobrien thanks, also did you add ACM access (3rd bullet point) there?
Sorry @mvadkert I missed that point, I'll email kevin to discuss what level of access is best. As with all tickets at the moment it may take some extra time due to the datacenter move.
I know that, everything here is not blocking us now, we can live with invalid certs until GA (planned for August)
@mvadkert with regard to ACM access, what is the domain name that you would be using? Would it need any alternative names for the cert?
If it is one of our existing ones we would need to import a cert for you and set up a cname record on our DNS servers to verify it.
@mvadkert can you reply to @mobrien 's questions above when you get a chance?
@mobrien @kevin sorry for the late reply, we are now living with letsencrypt, but it is a bit pita ...
ideally we would need to be able, for the start, to generate certs for *.testing-farm.io ....
ok. Do you control the testing-farm.io dns? ACM will want you to put a token in your dns to prove you own the domain or the like.
@mobrien I don't see off hand a way to restrict ACM access in iam to a specific domain. It looks like you can do sepecific certs, but not domains? Or am I missing something?
@mvadkert if the number/name of certs is known, we could just issue them and set them to auto-renew for you?
@kevin you are correct, there is no way to limit ACM by domain. We'd have to go the usual tag route. You can actually request a single cert with multiple domain names in ACM so I would guess that is why they don't allow limit by domain.
Ack, yes we control it fully
@mobrien I don't see off hand a way to restrict ACM access in iam to a specific domain. It looks like you can do sepecific certs, but not domains? Or am I missing something? @mvadkert if the number/name of certs is known, we could just issue them and set them to auto-renew for you?
Yep, it would be (for now):
testing-farm.io api.testing-farm.io api.dev.testing-farm.io api.staging.testing-farm.io metrics.infrastructure.testing-farm.io
Sorry this has been sitting here so long. ;(
In order to setup certs for those domains, amazon needs to confirm we manage/own them. You can do that via dns (they give us a record to add to dns) or email (they spam all the contacts of the domain in whois and they have to reply that it's ok).
see: https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-validate-dns.html
Which one would you like to do? If dns, I can email you the things they want added.
Second, do you want seperate certs for each of those domains? or one cert that has the other names as alternative?
@kevin no problem, we are living somehow with letsencrypt, but with kubernetes based apps it is harder to do ...
We can do DNS based validation
Rather separate if possible
Metadata Update from @pingou: - Issue tagged with: aws
@mobrien do you think we can finish this off?
Metadata Update from @smooge: - Issue tagged with: ops
We can drop this, we can do LetsEncrypt and not to do work to anybody.
Metadata Update from @mvadkert: - Issue close_status updated to: Insufficient data - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.