Feature Request: Support AWS capability to Associate an IAM role to a service account
antoniordz96 opened this issue · comments
Issue
The Cloud Watch forwarding integration in the ClusterLogForwarder CRD currently only supports passing credentials via a Kubernetes secret and is a required field in the CRD. At my organization, we are not allowed to generate AWS Credentials, we are expected to use the following capabilities (associate IAM role with a service account):
- https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-technical-overview.html
- https://docs.aws.amazon.com/eks/latest/userguide/specify-service-account-role.html
Describe the solution you'd like
I would like for the cluster-logging-operator to:
- allow configuring the AWS sdk client via credentials passed through the service account annotation. Client Library can be configured to handle old and new capability (https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-minimum-sdk.html)
- Allow via the ClusterLogForwarder CRD to set the AWS Role ARN thus the service account is annotated properly.
Describe alternatives you've considered
- Running own version of fluentbit/forwarder.
- deploying elasticsearch but for a small sized cluster this can be expensive.
Additional context
- I was able to test the AWS Annotation and install the operator in an openshift 4.9 cluster. Things were running smooth until I configured the log forwarder. I was able to set the AWS Annotation on the service account without OLM removing it, but I saw error from the DS pods that it was unable to send logs to cloud watch.
Environment:
- Openshift 4.9 Cluster
@antoniordz96 Are you able to see https://issues.redhat.com/browse/OBSDA-59 ? Does it cover your usecase?
Hey @jcantrill , thanks for sharing this! I do indeed have access but I think they still wanted to pass credentials via the secret?
In my proposal all that would be required is adding a new field to the CRD specifying the ARN and updating the operator logic to add the aws annotation to the service account and updating the client logic fetching credentials from the appropriate place.
In my proposal all that would be required is adding a new field to the CRD specifying the ARN and updating the operator logic to add the aws annotation to the service account and updating the client logic fetching credentials from the appropriate place.
I defer to our architect @alanconway here but I would generally n'ack the idea of updating the CR to allow passing the ARN. The intent of pushing it via secret is so works the same as all other auth methods for other outputs; this proposal would vary from that.
@cahartma does any of what describe here complicate/simplify what is currently implemented?
@jcantrill its adds another component to our generator spec, but should be straightforward.
@antoniordz96 I agree with @jcantrill, current design intentionally puts all authz and authn credentials in a secret because:
- part of it must be secret (passwords, certs, etc.)
- the parts that are not necessarily secret are usually closely associated with the secret stuff (e.g. username tied to password)
Can you elaborate on why you would prefer to store the role in the CRD instead of the secret? There's no difference in terms of implementation, my concern is keeping the API simple and consistent, where similar things are done in similar ways.
Apologies on late response...been busy
Can you elaborate on why you would prefer to store the role in the CRD instead of the secret? There's no difference in terms of implementation, my concern is keeping the API simple and consistent, where similar things are done in similar ways.
@alanconway, To me it's no preference I just want the operator to support the OIDC IAM capability. With that I don't consider the ARN a secret as even in today's implementation the arn is added as an annotation to the k8s service account. It's not hidden anywhere.
I would agree it is not a secret but that is not really the point from the CLO perspective. All other auth parameters are kept in a secret and continuing that pattern means it is consistent. There are minimal changes to be made for the collector to consume the role.
Cool I'm good with the decision then. I'll just wait for this work to be completed to be able to test it out. Our team is looking forward to switching to CLO rather than our own custom fluent bit.