The provided CloudFormation stack creates a Cross Account IAM Role with a list of read only permissions. We don't accept access keys or secrets.

- A permissions overview is here (most aren't used for now). This list was made from the AWS-managed IAM policy of "ReadOnlyAccess" but whittled down to remove things like our ability to read from S3 Buckets or Databases: https://docs.vantage.sh/permissions/

- The latest CloudFormation stack is here: https://vantage-public.s3.amazonaws.com/x-account-role-creat...

As for security, we are leveraging best practices learned from our time at AWS and DigitalOcean. Every person on our team has spent time at a public cloud provider and applying what we've learned there to Vantage. We've also been in contact with certain AWS employees to ensure we have proper setups.

I'm so refreshed to see this designed this way. I assumed that they would be asking for an API key or equivalent, because I don't know anything about the product team or the company and this bad behavior is so bog-standard.

I beg you to blog heavily about this approach, especially if you find success with it / it doesn't provide a very negative user experience. See if you can get featured on enterpriseready.io or something.

Hey, thanks for that comment and I'm glad folks are noticing our approach. We are happy to blog about it. We've had a tremendous amount of success with it.

Security is a top concern of ours and this was really the only option for what we are doing.

I am confused by your comment. How do they access the role they create if not through keys?

You can allow IAM roles in your account (which simply just has the permissions defined, with no keys or other credentials associated) to be assumed by identities in another account. Vantage would then be responsible for securing credentials for the target identity in their account, but there would be no transfer of keys involved whatsoever from one party to another.

You can create a role with certain permissions in your account. You can then configure this role to only be assumed by another user in another specific AWS account.

This is how you can share resources between different AWS accounts.

for what its worth, there is a much better scoped ViewOnlyAccess managed policy that makes a much better distinction about what is reasonable read-only access (ecs:listClusters) and not reasonable read-only access (dynamodb:Query)

That's good feedback. Customers can also give us a Cross Account IAM role with whatever permissions they'd like and Vantage should work accordingly in a gracefully degraded fashion.

For example: If you only want to give us access to EC2, things should theoretically work.

To use a custom cross account IAM role all you need to do is email [email protected] and we can help out with some other configuration details to get it going.

It appears the current CF stack is not valid JSON file:

$ http https://vantage-public.s3.amazonaws.com/x-account-role-creat... | jq '.' parse error: Expected another key-value pair at line 420, column 17

(Haven't tried to execute it with CF)

There's a trailing comma after the last kv pair in a dict. One of those things that some json parsers will accept and some won't.