Should I create an administrative user separate from my personal IAM user for creating my Amazon Managed Service for Prometheus workspace?

0

Summary: where can I add permissions for my AMP workspace to, for example, write to logs. It looks like it worked if I added log writing permissions to the IAM user that created the workspace, but surely that can't be what I am supposed to do?

Background

My organization created an AWS root account several years ago, which they then used to create several IAM users which we as developers use to create and manage AWS services. I was logged in as my IAM user when I created an Amazon Managed Service for Prometheus (AMP) workspace. I have deployed several Prometheus server instances using Fargate/ECS, which remote writes to the AMP workspace, and uses the AMP workspace as a datasource in Managed Grafana, and that all works as expected.

I noticed that even though I had configured Cloudwatch logs for my workspace, I didn't get any logs or even logstreams in Cloudwatch. I posted a separate question for that: Not getting logs from Amazon Managed Services for Prometheus workspace in Cloudwatch and got an anwer that made me look at the documentation again. According to https://docs.aws.amazon.com/prometheus/latest/userguide/CW-logs-config.html, to configure Cloudwatch logs I should add a number of permission policies to my role or user. I added the suggested permission policies to my personal IAM user, changed the log group for my AMP workspace to make sure it was updated, and then got a logstream in that log group with a message: "Permissions are set correctly to allow AWS CloudWatch Logs to write into your logs while creating a subscription". My interpretation is that this means that the logs are working.

Questions

  1. Is it the permissions of the IAM account that creates the workspace that determines if the AMP workspace have the correct permissions, such as being able to create and write to Cloudwatch logs? And if yes, does that mean we have to create a separate IAM user/role to log in as before creating an AMP workspace instead of using my personal developer IAM user, since I don't want it to stop working if I leave the company and my IAM user is deactivated? https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-setting-up.html does not make this clearer.
  2. Have I misunderstood why it seems to have worked to attach the required permissions to my IAM user? If I should not add the permissions to my user, where/to what should I then attach the permissions?

Edit: added a summary.

LilyB
asked 4 months ago619 views
2 Answers
1
Accepted Answer

Hi there,

AMP uses the IAM permissions that's assigned to a user or role to determine which actions can be performed on the AMP resources. As stated in the document below, users and roles don't have default permission to create or modify Amazon Managed Service for Prometheus resources. To grant users permission to perform actions on the resources that they need, an IAM administrator can create IAM policies. The administrator can then add the IAM policies to roles, and users can assume the roles. You can however just assign the IAM policies to the users themselves if you do not wish to add them to a role or group.

[+] https://docs.aws.amazon.com/prometheus/latest/userguide/security_iam_id-based-policy-examples.html

Please see the answers to your questions below:

  1. It is the IAM permissions of the user who is interacting with the AMP workspace that determines the correct permissions. So everyone who will be interacting with the workspace would need to have the correct permissions assigned to their IAM user.

  2. You have not misunderstood. You would need to adjust your IAM permissions in order to get your cloudwatch logs working with AMP.

answered 3 months ago
  • Thank you for your answer, and sorry about the late reply. The reason I asked this question in the first place was that I was not getting logs from my AMP workspace. I added a policy with permissions to create logs for the specific workspace to the user I had used to create that workspace. I then got a logstream in the log group with an entry stating "Permissions are set correctly to allow AWS CloudWatch Logs to write into your logs while creating a subscription." I figured that have solved the problem. However, two things make me question if my problem with not getting logs had anything to do with incorrect permissions after all:

    • The user I used to create the workspace already had permissions that should include create log group etc. I also did not get any error message when I enabled logs for the workspace in AWS Console.
    • I have still not gotten any other logs from my AMP workspace, even though errors have occurred which I think should result in error logs. I'm still confused as to what would happen if I removed the permissions from the user that created the workspace, or if someone without permissions updated the workspace. Would that revoke the permissions for the workspace to write to the logs?
0

How about moving those permission policies from your personal IAM user to the IAM user group you and the other devs are in? That should give you some breathing room while you wait for an expert to answer your other questions.

profile picture
answered 3 months ago
  • Thank you for your suggestion! At the moment this is not a problem for me since my account will nto be removed in the forseeable future. My question is more to get an answer to if this really is how it works, since it leads to so many problem managing AMP workspaces. I am comparing to an ECS service task for example, where you connect IAM roles and execution roles to the task to give it permissions to do what it needs to do. It seems very weird if for a AMP workspace this is instead done by adding permission policies to the user who created the workspace. I must have misunderstood something.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions