Grant user policy (IAM)

[Jicxer]

The users must specify the locations or resources needed in a configuration or command line. Each source log creates a table to store the contents.

The main idea is to check if the user has the policies required to execute the necessary actions. If not, they should contact an IAM admin to start sending logs. The user should be assigned to a user group or role for a customer. The policies within this role should include the least privileged permissions. The policies include: Creating a table Writing a table Firehose

Updates

User Groups

User: Created a user group called "user". Created a test-user to interact with dynamoDB and Kinesis Firehose. Permissions:

• AmazonDynamoDBReadOnlyAccess
• AmazonKinesisFirehoseReadOnlyAccess
• IAMReadOnlyAccess

Administrator: Created a user group called "admin". Contains all the permissions that we already have. Permissions:

• AmazonDynamoDBFullAccess
• AmazonKinesisFirehoseFullAccess
• AmazonKinesisFullAccess
• AmazonS3FullAccess
• IAMFullAccess

Issue Tasks:

• [x] Creating a group user for a customer on IAM Identity Center
• [x] Create an admin group
• [x] List user policies
• [x] Check the user policies for basic privileges
• [x] Return an error message if not
• [x] Update the read me for admin
• [x] Test admin functionality on a test user for AWS CLI command
• [x] Add more functionalities to IAM admin destination for client

Admin User:

The admin will be responsible for adding policies to the customer user. While this may not be possible on the client, the AWS CLI tool provides a method of accessing and editing user policies for an admin. This will need to be specified on the README.

User

The user will be provided minimal permissions and policies. Once a user creates a profile and attempts to access the client without the necessary permissions the client code will throw an error. The main functionality for implementing IAM on Rust SDK would not be to assign role or policies to users through the client code. It is to simply check the user permissions and required policies to execute the necessary tasks.

Current

Awaiting dynamodb to test user creating tables and adding items to table. This will be an ongoing proccess as we work towards implementing dynamodb. Currently, the creation of tables are being done under the assumption of admin permissions. We will need to use a test-user with user user-group permissions later on.

Resources:

Best-Practices Policies and Permissions Business-Best-Case-Practices

[Jicxer]

I will update this issue as I figure out what specific policies.

[endepointe]

remember that this might not be possible in the client code itself. It is going to be easier to do using the aws cli, which would be separate from the client.

Consider allowing the user to enter the aws cli the same way that destinations are specified as arguments.

Something like: cargo run -- run-admin perhaps?

[Jicxer]

This was an older issue which primarily focused on assigning roles to admins and users. At most, I created a file in rust within the client that serves as IAM policies and restrictions. Users should be able to enter the client; send the data to AWS. Admins should be able to access the AWS-CLI on the client but users can't.

So far, this is working. Yet, I've still the need to test whether these are working and commands are accessed correctly. The main issue is that I don't know what resources we will be accessing in AWS. So I wouldn't know what privileges to assign the user/admin. However, the code checking for these privileges work. It simply checks if the current user accessing the client has admin/user credentials. This is through the current AWS credentials that are provided in /aws/configure file.

[Jicxer]

After looking at the code last night, I realized the IAM CLI implementation is somewhat redundant. The CLI is based off the program and makes use of the actual terminal and simply types "aws" along with any other command the user wants. Why it's redundant:

• Requires that the user already has aws (they may as well just type in aws)
• Checks for the admin user (users should also be able to access this but should not be able to modify any resources and IAM itself already manages this - we don't need to do it)

Regardless, we can leave this functionality in. But I believe that the admins or users (if they need to manage their user) should just simply do it on AWS or command line.