Stricter IAM permissions #37
Conversation
start restriction for more fine-grained control policies
| @@ -125,6 +124,36 @@ data "aws_iam_policy_document" "segment_data_lake_policy_document" { | |||
| effect = "Allow" | |||
| } | |||
|
|
|||
| # Explicitly deny Segment to modify IAM or sensible configuration from the Data Lake S3 bucket. | |||
| statement { | |||
There was a problem hiding this comment.
Is it OK to deny these actions?
There was a problem hiding this comment.
Yes we do not make any of these API calls so denying these sounds good 👍
| @@ -44,7 +44,6 @@ resource "aws_iam_policy" "segment_data_lake_policy" { | |||
| path = "/" | |||
| description = "Gives access to resources in your Data Lake" | |||
| policy = "${data.aws_iam_policy_document.segment_data_lake_policy_document.json}" | |||
| tags = "${local.tags}" | |||
There was a problem hiding this comment.
Policies can't contain tags :(
| resources = [ | ||
| "*" | ||
| ] | ||
| # Check that were created by Segment |
There was a problem hiding this comment.
Here is where I need your collaboration. Can we filter these actions to specific tagged resources?
There was a problem hiding this comment.
So the role to which this policy is attached is the EMR service-linked role that is only assumed by the EMR service to perform administrative tasks. You can see that in the assume-role section of the segment_emr_service_role role definition. Data Lakes directly nor the jobs running on the EMR cluster use this role.
We have used the default policy for this role given that this is only used by the EMR service and it's not clear what the effect of limiting the access here would be. You can read more about this role here.
These are the roles used by Data lakes to access your resources and we can tighten the permissions for this if required. We have already limited access to an extent but adding some explicit Deny rules makes sense.
segment_data_lake_iam_role
segment_emr_instance_profile_role
| effect = "Allow" | ||
| } | ||
|
|
||
| statement { |
There was a problem hiding this comment.
Is SQS needed?
If so, can we please constrain to certain tags the affected resources
| effect = "Allow" | ||
| } | ||
|
|
||
| statement { |
There was a problem hiding this comment.
I think this one is too broad, as this would allow Segment to access all the S3 objects not explicitly restricted in their BucketPolicy
|
Thanks for the feedback @carlosescura 👍 We would be happy to incorporate some of these changes but it might take a bit of time to test and release it for all existing and new customers. In the meantime, I would recommend you can unblock yourself by tightening some of the polices that you mentioned in the PR and using this branch as the source in the terraform |
| "iam:GetRolePolicy", | ||
| "iam:ListInstanceProfiles", | ||
| "iam:ListRolePolicies", | ||
| "iam:PassRole", |
There was a problem hiding this comment.
iam:PassRole is a very powerful privilege. If role/policy must use it, then please specify what roles can be passed. Otherwise, this way you are granting permissions to pass any role within same AWS account (including admin roles)
I would like to discuss several parts of your proposed policies in order to stiffen the IAM control, as DataLake is one of the most valuable pieces of every single enterprise.
My proposal would be to discuss the commented lines of code, and also ask for your collaboration tagging all your created resources, so we can keep some of the IAM permissions, but constrained to a certain set of conditions (such as resource tagging)