Not necessarily. An AWS account ID + the knowledge of a role name that by mistake has the "allow role assumption" allowlist too wide (say "*") is now enough to take over the account.
One might of course say "well then don't do that", but of course the more complex a system like IAM is the easier it is for unexperienced people to open the floodgates.
That's easy to find out: change the API credentials of a user, but forget to update the service. Notice only a few days later that you forgot the change, but you also never got any notification "something" is going wrong.
In contrast, every half-decent IdP will lock an account automatically after anything from 3-10 wrong attempts.
Turning what you said around, you're arguing you might want to keep an account ID secret for "security by obscurity" reasons. In my mind, even in a multi-layer security solution, even then the account ID should be considered as a public string whose knowledge (along with other bits like what misconfigurations it has) provides no additional vector of attack, because of defense in depth.
Not necessarily. An AWS account ID + the knowledge of a role name that by mistake has the "allow role assumption" allowlist too wide (say "*") is now enough to take over the account.
One might of course say "well then don't do that", but of course the more complex a system like IAM is the easier it is for unexperienced people to open the floodgates.