This message was deleted.
# general
s
This message was deleted.
k
It looks like the arn should be of the form
arn:aws:iam::{account}:{user}
e.g.
Copy code
{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::123456789012:root"
    },
    "Action": "sts:AssumeRole"
  }
}
from here
n
@kind-mechanic-53546 for my case I do not want to use
root
because I do not want to grant permission to all users of the account. And if you check the error message, the user ARN is actually correct
k
hmm, so the form user/username is correct?
hmm, looks like it
one way that I know works, is to create a group, allow that group membership to assume the role, then add users to the group
this is what I do in a couple of environments
n
if they are in a same account, yes, group is a good candidate. For my case, I want to experiment with cross-account access, so role is the option I went with.
I think the error might be related to the fact that user has not been created yet
k
also, it doesnt look like you're iterating over your users and creating a single role and allowing assumption by multiple users
when you say "2) apply then add another user:", what do you mean?
apply?
n
yes
pulumi up
then make changes to the
index.ts
to add another user
k
ok, that won't work, you need to add all your users, construct a role with an assume policy with all your arn's as principals
n
yes, that's what I want to do with the code.
FYI the 2nd time I run
pulumi up
for step 2the role policy is updated correctly
k
yes, it does kind of look like a race condition
this may work, but you might still have an issue with your users being created after the policy doc has run
Copy code
import * as pulumi from "@pulumi/pulumi";
import * as kubernetes from "@pulumi/kubernetes";

import * as aws from "@pulumi/aws";
const getAccountARN = (accountId: string, resource: string = "*") => {
  return `arn:aws:iam::${accountId}:${resource}`
}
interface UserList {
  [username: string]: aws.iam.User;
}
const accountID = "437763615564"
let users: UserList = {};
// create 1 user
const user1 = new aws.iam.User("user1", {
  name: "user1"
});
users["user1"] = user1;

// create 2 user
const user2 = new aws.iam.User("user2", {
  name: "user2"
});
users["user2"] = user2;

// create a new role with sts:AssumeRole for those users
const assumeRolePolicy = aws.iam.getPolicyDocument({
  statements: [{
    effect: "Allow",
    actions: ["sts:AssumeRole"],
    principals: [{
      type: "AWS",
      identifiers: Object.keys(users).map((username) => {
        return getAccountARN(accountID, `user/${username}`)
      })
    }]
  }]
});

const role = new aws.iam.Role("devs", {
  assumeRolePolicy: assumeRolePolicy.then(policy => policy.json),
  name: "super-uber-devs"
}, {
  //dependsOn: Object.values(users)
  dependsOn: [user1, user2]
});
n
I've tried that before too, sadly it does not work
k
the issue would be that your dependsOn will be a list of 0, 1 or 2 elements depending on the execution order, but I don't know the async creation model of pulumi
fair enough, I'm out of ideas sorry, role -> group -> users 🙂
n
@kind-mechanic-53546 great thanks with your help btw 🙇
k
no worries 🙂
n
@kind-mechanic-53546 I guess alternative solution is to have 2 stacks, one for creating users and the other for creating roles. The latter would get stack output from the first....
k
yep, I've had to do that in the past, works well
👍 1
groups are easier to manage though 😉
g
@narrow-jackal-57645 I tried JohnB's code and did not see the same error as you did. Therefore, I think what you're seeing is a race condition, not within Pulumi, but within AWS. IAM is eventually consistent (see https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) which means that if you create an IAM resource and then try to reference that resource too quickly, that second resource can fail if IAM itself is still replicating the data about the first resource. So, to work around this, we can introduce a "sleep" after your user resources and before the Role is defined. Here's a generalized example of that, https://gist.github.com/clstokes/82015297eba3c4caa9b0b46dd232b079, let me know if you need help making that work in your code.
👍 1
w
Ouch. Does this happen very often? I've only had to deal with this for an EKS cluster so far, and at least that has an endpoint you can query.
g
Being a global service as opposed to a regional service, IAM is much more susceptible to this than other AWS services. Googling for "aws iam eventual consistency" will return lots of results over many years of people encountering this. 😣
😫 1
n
Great thanks to @gentle-diamond-70147
your work-around suggestion works for me
g
Glad to hear it!
👍 1