-
Notifications
You must be signed in to change notification settings - Fork 103
Create IAM Role Resource #59
Comments
hey @christopherhein ! What do you mean with
Does it mean that the IAM Role Resource should be created in a shared namespace instead of the same namespace where the application is running? |
The idea here is in AWS IAM Roles and Policies are treated at the global namespace meaning they are shared across regions, in Kubernetes and AWS we have the concept of namespaces but then we also have cluster wide components like |
We'd need to reference other AWS resources created by this operator like S3 buckets, in the Policies that would be attached to the IAM Role for the application. If we want to programatically create this policies, maybe we should label the AWS resources created in the Kubernetes API with the application name, try to filter using the label and take the |
That wasn't my initial thought, how I'd originally envisioned and started prototyping this was using #58 for the policies, treating them more like we treat So if you check out the example: apiVersion: operator.aws/v1alpha1
kind: IAMRole
metadata:
name: aws-operator
spec:
policies:
- aws-operator
- AdministratorAccess the keys under
|
I see. But do you think this would make sense?
This role would be used by Normally, we don't share AWS resources like databases, S3 buckets or KMS keys between applications. That's why we'd like to limit the access to the application. |
I would love more feedback on this but I don't think the solution outlined precludes what you are saying actually. It just models the resources similar to the way the AWS IAM is modeled being a global service… if you make a policy or role it's accessible to region A and region B. The way it is structured in that sample manifest allows you to use of all policies including the standard policies in every AWS Account, (the whitelist) from within the role and they get backed up to individual policies outside of the role. This enables but doesn't force other roles to use that same policy. An example of this could be two applications that need write capability to an SQS queue, you could write the policy once and reference it in the two separate roles one for each application. What we lose by structuring it this way is inline policies, is this a deal breaker? Given that the operator is creating and managing those resources for you, you likely won't need to do anything in the console to make this happen. To give a more clear example if you had a role/policy that needed write access to ---
apiVersion: service-operator.aws/v1alpha1
kind: IAMPolicy
metadata:
name: foo-app-sqs-policy
spec:
sqs:
write:
- SendMessage
resource:
- arn:aws:sqs:*:123456789012:foo-app
---
apiVersion: service-operator.aws/v1alpha1
kind: IAMRole
metadata:
name: foo-app-role
spec:
policies:
- foo-app-sqs-policy Then if later in development you need to mutate the role and give it read-only S3 access you can simply mutate the Doesn't that help? Concerns? |
I like the separation of concerns with |
Hello @christopherhein ! Any updates about creating IAM resources with aws-service-operator? I would like to try it. |
Yeah, managing IAM resources is a hot issue for me at the moment. |
Hey @christopherhein, any movement on the code gen part of this project? I'm pretty interesting getting the IAM into the operator and would like to help if needed. I'm a noob to operators and Go but happy to give it a shot if you're open to it. Let me know where it's at and where I can help, if at all. |
This will allow you to model an IAM role for your applications. These will reference policy names either via the name in IAM from defaults or using the IAM Policy resource in #58.
This should be a cluster-wide resource, as well when they use a standard policy name it should use
aws
as the account id in the arn.whitelisted policy names
The text was updated successfully, but these errors were encountered: