AWS Glue — Administrator Role not justified !!
Many times when someone is giving a demo or creating an article or technical video tutorial, you will notice that they mostly use the AWS Administrator Role, but do they really need an Administrator role? not really. Seeing them viewers builds an expectation that when they are building the solution they should use the same roles and permission.
Administrator Role is an easy solution but we need to realize, that if users are not careful with AWS Keys and Secret keys, it opens up a hole for security breaches that the infrastructure team, DevOps team, or cyber-security team tries to control daily.
Here are some of the ways Developers, DevOps or Cloud Administrators should try with minimum access permission followed by elevating the access permission as needed on a case-to-case basis.
To set up IAM permissions for AWS Glue
- Sign in to the AWS Management Console and open the AWS Glue console at https://console.aws.amazon.com/glue/
- Under Prepare your account for AWS Glue, choose Set up IAM permissions.
3. Choose the IAM identities (roles or users) that you want to give AWS Glue permissions to. Assuming there are no existing custom roles that is created here, Lets make one
As you can see we already have some frequently used roles defined considering some known cases like Access to Glue with Specific User Restriction, Notebook or Sagemaker, etc. Unless you are looking for mentioned specifics start with AWSGlueServiceRole
AWSGlueServiceRole comes with Full access to AWS Glue and commonly used AWS services around it.
AWSGlueConsoleFullAccess, comes with elevated access over AWSGlueServiceRole and limited to full access to 131+ AWS services
Now that we have identified AWS Glue access, let’s choose the right access for the S3 bucket, following the approach we took earlier. Without choosing AmazonS3FullAccess, as there is no need to have the ability to make changes to those S3 buckets that are out of the scope of work done by your AWS Glue Project, so requesting access to only those specific buckets makes sense.
Grant access to specific Amazon S3 Bucket (read-only): If the project requires only reading the information from the S3 bucket and not modifying or adding any changes to the S3 bucket.
Grant access to specific Amazon S3 locations (read and write): Elevating the access here, if the project is not only reading the information from the S3 bucket but also wants to add content related to Athena results, Glue Script files, Job run logs, source and/or target database, etc.
Role assignment doesn’t need to be permanent, it can always be improvised. Least privilege is a popular policy, but it can be difficult to operationalize. Figure out who will be affected by the changes, then communicate the new process to them. In the end objective of creating custom roles should meet the purpose of the person using the tool as well as the person responsible for security and governance.
I appreciate you and the time you took out of your day to read this! Please watch out (follow & subscribe) for more, Cheers!
