refactor(snapshot): address nits

[jta]

This commit addresses nits uncovered in #58 which were also applicable to the snapshot module.

[bendrucker]

I think this is still going to fail for roles with a path. As I understand it, the idea behind paths is that you can craft broad but safe rules with wildcards. Whereas use of wildcards in names is considered an anti-pattern.

Good:

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::account-id:role/engineering/*"
  }
}

Bad:

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::account-id:role/engineering*"
  }
}

The non-path wildcard may match unexpectedly on partial words, whereas paths are very explicitly hierarchical.

But paths are a weird half-embraced feature and don't factor into uniqueness. A role name must still be unique. And I'm pretty sure the parameter here is always the role name, without the path.

https://stackoverflow.com/a/46325139

This is a mildly contrived issue as the role typically being passed in here doesn't have a path. But strictly speaking, that's a loose dependency, and according to the input type (object) there's an edge case bug here.

[jta]

Ok, I had to read that stackoverflow twice and your explanation is actually clearer. When you originally brought the issue up, I misinterpreted it as being a case of inadvertent pattern matching (i.e. what happens if path includes ends in role).

The behavior where path is not part of the identity, but is just a grouping key is a bit uninituive, and we probably need to review how we model IAM in OPAL.