Open christopherhein opened 6 years ago
I'm not sure I understand where you are going with example provided. Wouldn't it make sense to have 'actions' and 'resources' as spec values?
apiVersion: operator.aws/v1alpha1
kind: IAMPolicy
metadata:
name: app-foo-dynamodb-access
spec:
actions:
- dynamodb:*
resources:
- arn:aws:dynamodb:us-east-2:123456789012:table/app-foo-*
I'm not sure I understand where you are going with example provided. Wouldn't it make sense to have 'actions' and 'resources' as spec values?
apiVersion: operator.aws/v1alpha1 kind: IAMPolicy metadata: name: app-foo-dynamodb-access spec: actions: - dynamodb:* resources: - arn:aws:dynamodb:us-east-2:123456789012:table/app-foo-*
Definitely, this will be really useful and I have some ideas around the resources
, I'm trying to design a better strategy for referencing resources similar to how k8s core does with configmaps and secrets I could image this being something like:
- arn: {arn} # or arn with wildcards
resourceRef: # optional if you'd like to reference a Kubernetes managed AWS Resource
name: {name}
namespace: {namespace}
Wanted to checkin and see if any more progress has been made on the design of this. I'm curious how you would address assume role and inline policies.
This will allow you to create an IAM Policy that you can reference from an IAM Role, giving you the ability to give out specific permissions to every role.
Long term when you build a syncing tool, use this to load existing policies in IAM that way they can be referenced via the Roles OR use the same naming scheme to allow you to use any standard policy name.