Hi!
Here is another post with some spoilers from our product roadmap.
Context
As of today, the pods of the applications deployed by Qovery on your kubernetes cluster have the minimum set of permissions that can be given to a pod (basically). This means that your application is not capable to access the information of other pods, creating new pods or editing existing pods.
Same story when it comes to managing cloud provider resources (like creating an RDS instance via a lifecycle job), your application has no permission. You can provide these permissions to your application by either adding the cloud provider credentials as secrets for your application OR by relying on the assume-role functionality of AWS (via the creation a service account, more information on this here). We have provided a guide on how to setup the service accounts but it is not so simple and it requires a few steps to achieve the final setup.
Feature
We will work soon on a feature that will let you manage both the Kubernetes and AWS permissions in one place, avoiding error-prone configurations requiring multiple configuration steps.
In this new section of the console, for the selected application you will be able to configure:
- the Kubernetes permissions that your application will have based on the RBAC kubernetes API access authorization (Using RBAC Authorization | Kubernetes)
- the ARN of the role that the pod will have to assume when accessing AWS resources.
Based on this setup, Qovery will take care of creating the Role/ClusterRole, RoleBinding/ ClusterRoleBinding and Service Account on your cluster, including the required annotations on the service account to link the IAM role (note, you will still have to create the IAM role and the OICD configuration on your cluster)
Roadmap items:
- https://roadmap.qovery.com/roadmap/configure-kubernetes-permission-of-the-application-kube-rbac
- https://roadmap.qovery.com/roadmap/simplify-configuration-of-service-account-for-applications
Feel free to add comments / suggestions below 
Alessandro