V2

[tilfin]

156

[tilfin]

V2 (2.0.3) release

Revision changes

2.0.3 at 2020-09-24 11:10 JST

• Fix to obtain the alias of base account
• Fix the initialization

2.0.2 at 2020-09-23 22:45 JST

• Fix the display name being lowercase after the switch
• Revert filtering with case-insensitive
• Fix some styles in the pop-up
• Tune the initialization timing
• Change the color of this extension icon blue

Major Changelogs

• Change showing the Role List UI from a browser extension menu outside the AWS Console page
• Abolish 'Hide original role history'
• Abolish attaching color line on the bottom of the AWS Console header
• Abolish inserting the profile image into the AWS Console header even if the image parameter is defined
• Disable 'Show only matching roles' temporarily
• Disable 'Automatically assume last assumed role (Experimental)' temporarily
• Change the color of this extension icon

Known Issues

🔴 The issue about the Complex configuration when your master account has the alias 🔴

~~When you give the master account the alias, your role is not shown. This issue is resolved by changing from an alias to a number ID. However, you can't switch between assumed accounts after you swithed one of the role list from base account. The reason is that account ID (numbers) is shown on the menu of the master but the alias is shown on the menu of assumed(switched) one.~~ Revert to using your account alias if you change using the ID (numbers)

ScreenShot

Chrome

Firefox

[csrl]

It is generally functioning, however I have to click the extension icon twice to get the menu. First time, no menu shows up (well a tiny menu indicator that is completely empty), second time the full menu appears. This is repeatable on every use of the menu. Firefox 77.0.1

Also, is the extension icon going to be the only way going forward? Vs modifying the aws console role history dropdown as previously? If so, is it possible to auto-hide the icon when not viewing an AWS console page?

Thanks for this quick turn around on this compatibility update!

[tilfin]

@csrl Thank you, feedback. I investigate the phenomenon on Firefox.

Also, is the extension icon going to be the only way going forward?

We proceed as it is since it is difficult to maintain the UI so far.

auto-hide the icon when not viewing an AWS console page?

It is probably difficult and it increases the permissions that this extension requires. therefore I don't intend to implement it.

[kjones]

Thanks for the quick fix. Just downloaded and installed the V2 pre-release. All working great except I had to change my base account from using the alias to instead use the account number.

Old config example:

[base-account]
aws_account_id = base-account-alias

Changed to:

[base-account]
aws_account_id = 111222333

[tilfin]

@csrl

This is repeatable on every use of the menu. Firefox 77.0.1

That doesn't happen anymore. If the page is not fully loaded, it may not be displayed before the page has finished loading, as the necessary information is not available.

[tyrken]

We proceed as it is since it is difficult to maintain the UI so far.

Echoing @csrl's original posting, it would avoid the need to retrain a lot of users if the original extend-aws-menu functionality came back.

I know sitting on an undocumented API is risky but it worked for many years and was very intuitive. AWS @kareemdarkazanli did seem willing to cooperate a little, and we can keep the new extension-icon menu as backup...

[tilfin]

The method of extending the role list needed to be modified to display a lot of list items #110. The extension don't use any undocumented API, just HTML scraping, so I'll have to keep up with the changes of AWS Console page.

I have received some donations, and I am very happy about them. However, even in total amount, it is only one luxurious dinner. I'm sorry that does not keep me motivated to develop this extension. So I want to become it as 'simple' as possible.

[tyrken]

Understood & already Paypal'ed yesterday - but no-one is in Open Source for the money (without a day job).

I've lent on our AWS TAM to see if they can make your life easier, if anybody else could do similar that would be appreciated. Certainly between this extension and our own private one (which does roughly the same job as https://github.com/prolane/samltoawsstskeys) this is the sweetest AWS experience I've seen in a few companies.

[tilfin]

@tyrken Thank you so much for your donation.

I don't believe that relying on certain people is not equitable. I think all users of AESR are equally AWS customers. I've been in contact with the developers of AWS by this issue. I would like to discuss the future of AESR later.

[pjmcquade]

@tyrken Thank you so much for your donation.

I don't believe that relying on certain people is not equitable. I think all users of AESR are equally AWS customers. I've been in contact with the developers of AWS by this issue. I would like to discuss the future of AESR later.

I also donated BTC to you today. I have used this extension extensively at work. I feel bad to ask people to fix things if I've benefited from them without offering something of value.

Thanks again!

[timschill]

While being in my master account I can switch role to all the other accounts. But from one of my assumed accounts I can not switch to any other account? Config looks like this:

[master-1]
aws_account_id = 0000000000000

[profile master1-account1]
role_arn = arn:aws:iam::0101010101010:role/My-Role
region = eu-west-1
source_profile = master-1
color=ff9300

[master-2]
aws_account_id = 111111111111111

[profile master2-account1]
role_arn = arn:aws:iam::020202020202020:role/My-Role
region = eu-north-1
source_profile = master-2
color=ff9300

[tilfin]

@timschill Is that a problem that has occurred since you installed to V2? profile master-account1 is wrongly duplicated. Even assuming that's a typo, it's a natural behavior since one assumed account for each master one.

[timschill]

Yes sorry the example was modified from the original. My config has worked in previous version the only difference here is that i have updated the master account from using an alias to the account number. I updated my example, I also played around changing the region, like use the same region as my master account. But im only able to switch from master to any choosen accounts but still cant go from there to yet another account. Going back to master let me switch again doe. Perhaps this might be of use

Uncaught ReferenceError: ConsoleNavService is not defined
    at attach_target.js:21
    at attach_target.js:44

[simonscholey-nasstar]

Thank you for your hard work to get this working @tilfin. It seems fine to me and I have a mixture of simple and complex configuration.

[tilfin]

@timschill I understood. if you give the alias of account, you cannot switch another assumed account after the switching from master account. The reason is that account ID (numbers) is shown on the menu of the master but the alias is shown on the menu of assumed one. I'm working on this with an AWS developer.

[timschill]

Understood and thank you for the great job you are doing. A little thank you paypal donation is on it's way.

[Fran-Rg]

Quick wiki on how to transition from 0.15.0 to 2.0 on Chrome with this "beta" version.

1. Download the zip for chrome from here: https://github.com/tilfin/aws-extend-switch-roles/pull/157#issuecomment-694912913
2. Unzip in a place that won't move on your disk
3. Take a copy of your current AWS Extend configuration
4. Got to the extension manager: chrome://extensions/
5. Turn on the debugger mode (top right)
6. Disable "AWS Extend Switch Roles 0.15.0"
7. Click on load unpacked (top left) and select the directory you unpacked for the zip: "aws-extend-switch-roles-v2_chrome"
8. A new extension should be added to the list: "AWS Extend Switch Roles 2.0.0"
9. Place the copy of the configuration in the new extension options
10. Once on AWS console, click on the extension icon (make sure to pin it) and you should see the list of accounts/roles you can switch to

[mtamassia]

@tilfin thank you very much for the release. It is working as expected in Firefox.

One small thing: I noticed that the add-on will have horizontal scrollbar if the profile name is longer than ~25 characters. Can we possibly auto expand laterally, up to a certain % of the page, or do something else to avoid horizontal scroll bars?

[tilfin]

@mtamassia In my environment, it's not occurred on both Windows and MacOS. It may happen if you change the screen zoom rate or something.

[mtamassia]

@tilfin

• FF 80.01 on Windows
• Zoom set to default 100%
• Screen Resolution 2560x1440

Sample Profile

[Xxxxxx-Yyyyyyyy Management]
role_arn = arn:aws:iam::000000000:role/XXXX
color = 3cb44b
region = us-east-1

[Yyyyyxx-Zztzzzzzx Management]
role_arn = arn:aws:iam::000000000:role/XXXX
color = 3cb44b
region = us-east-1

[mtamassia]

@tilfin the issue only happens when you have enough accounts that a vertical scrollbar shows up.

When I only have 5 or 6 accounts no scrollbars show up. When I have all our accounts 50+, the vertical and horizontal scrollbar shows up.

[eduardomourar]

Thanks for the quick fix. Just downloaded and installed the V2 pre-release. All working great except I had to change my base account from using the alias to instead use the account number.

Old config example:

[base-account]
aws_account_id = base-account-alias

Changed to:

[base-account]
aws_account_id = 111222333

The plugin worked with suggestion above. But in reality we have a little bit of a problem, because when logged in the base account, the menu only contains the account numeric identifier (attached image). But when logged in the target accounts, we only have the base account alias.

The simplest way I could find to fix this is by allowing the base account to contain both identifiers.

[tilfin]

I released v2.0.1 at the top of this comments.

@csrl The phenomenon will be improved in 2.0.1, but you have to wait for the Console initialized. @mtamassia It was probably fixed in 2.0.1. (You can have the screenshot erased.

[kjones]

Known Issues

🔴 The issue about the Complex configuration when your master account has the alias 🔴

When you give the master account the alias, your role is not shown. This issue is resolved by changing from an alias to a number ID. However, you can't switch between assumed accounts after you swithed one of the role list from base account. The reason is that account ID (numbers) is shown on the menu of the master but the alias is shown on the menu of assumed(switched) one.

I've gone back to specifying the alias in the configuration. The AESR role list is empty on first login to the master account, however, you can use the AWS Role History to assume your first role and thereafter the AESR role list will always show. This workflow is better for me since all work is done using an assumed role.

[whoDoneItAgain]

So far so good on this release. One minor thing I've noticed. The case of the role name doesn't translate to the AWS page. 'SS-Prod' shows as 'ss-prod'

[villeliskisolita]

I've tested 2.0.1 and found out that (in Chrome) the config file can't contain source_profile = [jump account alias] Something collided and the account list was empty, but when those lines were removed (pretty useless right now as "Show only matching roles (temporarily disabled)") the plugin works as expected. Thank you.

[timschill]

I've tested 2.0.1 and found out that (in Chrome) the config file can't contain source_profile = [jump account alias] Something collided and the account list was empty, but when those lines were removed (pretty useless right now as "Show only matching roles (temporarily disabled)") the plugin works as expected. Thank you.

I got account alias to work with 2.0.1, BUT you have to first click the switch role menu and jump to a account in the history. After that all accounts showed up in the plugin menu again.

Im running the complex configuration

[pjmcquade]

I got account alias to work with 2.0.1, BUT you have to first click the switch role menu and jump to a account in the history. After that all accounts showed up in the plugin menu again.

Confirmed. I had to do this as well.

[yannickvr]

Could be me, but with the old plugin the search wasn't case sensitive, seems now it is.

[mwarkentin]

Looks like this might be rolled out to all accounts/regions now? At least they've published their release blog post: https://aws.amazon.com/about-aws/whats-new/2020/09/usability-improvements-for-aws-management-console-now-available/

[tilfin]

I released v2.0.2 at the top of this comments.

@whoDoneItAgain @yannickvr I fixed your item pointed out.

[rpattcorner]

I got account alias to work with 2.0.1, BUT you have to first click the switch role menu and jump to a account in the history. After that all accounts showed up in the plugin menu again.

Confirmed. I had to do this as well.

[Update ... tested with 2.0.2 which was just released, and still see the issues below ]

Apologies in advance for the long post ... trying for some clarity here.

Inconsistent access to the role list in complex configurations is a serious problem for us as well -- especially because our AESR users are not technical and need a consistent experience. We can't reasonably expect them to move back and forth between two menus (AWS menu and AESR extension menu) showing similar items.

I suspect we're all describing the "known issue" in the 2.01 release notes above, but don't fully understand the explanation. The test scenario I observe is:

• Start on the AWS side with a base account that has an alias
• Start on the AESR side with a complex style configuration with a base account referencing the alias, and one or more associated account/roles

1. When AESR configuration specifies the alias for the base account value, zero role entries appear in the base account
2. When AESR configuration specifies the account number for the base account value, role entries appear in the base account but do not appear after assuming a child role associated with the base account

So we're unable to access and switch roles after initial login (case 1 above) or unable to and switch roles after any role switch unless we interrupt flow to go to the AWS menu then go back to a populated AESR display (case 2 above).

I think @tilfin is well aware of this problem from the "known issue" post in the 2.01 release notes and hopefully it's being addressed. Just speculating, it might be possible to extend the base entry syntax to include both the account name and number, with conditional logic to try the alternate style of access if an empty list of roles is returned. Something like:

[my-base-account]
aws_account_id = 123412341234
aws_account_alias = my-base-account-alias

[child account]
aws_account_id = 5678567685678
account_name = some-arbitrary-name-that-is-probably-not-read-by-aesr-but-is-useful-for-admins
source_profile = my-base-account
role_arn = arn:aws:iam::567856785678:role/SomeOldRole
color = 008000

and AESR logic like:

* wait for the console to completely render
* try to populate the roles list from config referencing the base account aws_account_alias entry
* if results are nonempty display them
* else try to populate the roles list from config referencing the aws_account_id entry
* if results are nonempty display them

So the only nonempty results would be if neither style of referencing the internal entries was successful.

Another possibility would be to deprecate aliases and use account numbers in all cases. This might or might not require AWS admins to forego the use of aliases entirely. I'm thinking that forbidding aliases with AESR may not be necessary based on my experience of ADFS federation, where the ADFS side can be configured to use an account number regardless of whether or not an alias exists.

One other suggestion ... the AWS menu has an entry labeled "Back to WhoeverYouLoggedInAs". Since we're going to have to educate our users to use AESR's menu instead of Amazon's to navigate roles, it would be excellent if that "Back to..." functionality could be presenet in the AESR menu as well. That will only be supportable by @tilfin if there's a reliable URL for that action though ... I think his whole point of putting the role switcher UI in the AESR plugin is to get out of the unscalable business of chasing AWS UI developers around.

Unfortunately adding the "Back..." capability isn't a complete solution, just a convenience. I can't see people accepting a flow that requires them to jump back to their base account every time they want to move to a new role.

For context, my team and I build and maintain a commercial GUI that manages the back end aspects of role switching, e.g. configuring the principals/users, creating roles and policies in the different target accounts, etc. Our management console users are technical, but the people actually jumping roles are nontechnical and need a very predictable experience. Either the standard Amazon menu or AESR will work fine for the role jumpers, but we recommend AESR because it's a superior experience. Asking them to bounce between AWS and AESR menus is unlikely to be accepted though.

I'm hoping that the new AESR UI under the extension can be enriched just enough to provide a complete experience for role switching. Or that AWS gets smart and purchases/supports AESR for a whole lot more than the cost of a great kaiseki!

[phivid]

Hello,

I use this pre-v2 plugin version and today wanted to add a bloc in the config part but error occured at extension level when saving:

Did I do something wrong ? 🤔

EDIT (23/09/2020@17:10): I upgraded to 2.0.2, no more error but no Roles visible anymore with a previous working configuration... EDIT (23/09/2020@17:43): Sorry, in fact, it's the same issue as @rpattcorner mentionned. 😅

[tilfin]

@rpattcorner It's as you understand it. I'm working on the issue with AWS developers.

[csrl]

@kareemdarkazanli breaking this plugin without first ensuring you have given the author the support and time necessary to keep it functioning is really unacceptable. The fact that AWS is not natively providing a solution and is abusing a free / open source developer's good will to solve a problem that a lot of high volume paying customers to AWS are utilizing is simply wrong.

Fix this.

@tilfin - thank you for supporting this plugin. I hope AWS does right by you.

[tilfin]

See https://github.com/tilfin/aws-extend-switch-roles/issues/156#issuecomment-698073728

[rpattcorner]

2.0.3 passes my little test setup in Commercial using aliases and a complex configuration

but ... we may have a regression as regards US GovCloud partition. Which will be painful because @tilfin probably can't test there. Please let me know what I can do to assist.

In GovCloud, formerly working in the same manner as commercial partition, "The Console is not yet fully loaded." message appears in the extensions menu, and never resolves. Probably something about the GovCloud console that's different.

Maybe the China partition behaves in a similar manner?

I'm working in US ET so will be available in the morning (where I am) if I can test or help.

[rpattcorner]

Just did a quick verify ... 2.0.2 indeed works in US GovCloud so the note above appears to be a true regression.

[rpattcorner]

One final weirdness that might point at the cause. For grins I enabled both 2.0.2 and 2.0.3 in the same browser and tested US GovCloud. I observe an interaction between the two in the following way:

• Start with both extensions available, logged into US govcloud base account, identified in config with an alias
• 2.0.3 does not show roles and gives "Console not fully loaded" message indefinitely
• Without reloading AWS, click on 2.0.2 version of extension. Roles are loaded
• Without reloading AWS or taking any other action click back on 2.0.3 version of extension. Roles are now loaded

Suggesting something active in 2.0.2 is pulling what we need, and interacting with the 2.0.3 extension window. Possibly might point things in a useful direction.

zzzzzzzz :)

[villeliskisolita]

I think @tilfin is well aware of this problem from the "known issue" post in the 2.01 release notes and hopefully it's being addressed. Just speculating, it might be possible to extend the base entry syntax to include both the account name and number, with conditional logic to try the alternate style of access if an empty list of roles is returned. Something like:

I'm strongly against this approach. As it is extremely detrimental to store two separate config files. One for AESR and one for aws-cli (and every SDK that consumes same format of config files that aws-cli does) If AESR would drift radically from the config file's format and those two would not be interchangeable that would drive users to develop their own scripts to generate one config from another and it would make managing n+100 accounts with n jump accounts even a bigger nightmare than it currently is.

[craighurley]

drive users to develop their own scripts to generate one config from another

already done that due to the number of different orgs I deal with: https://github.com/craighurley/aws-credentials-setup

[rpattcorner]

@villeliskisolita I think you may have misunderstood me ... I wasn't suggesting a second configuration file, or any relationship with the aws-cli's config, simply an additional line in the base configuration stanza of the existing AESR config, along with some differential logic in AESR. The question is now overtaken by events, as @tilfin has apparently resolved the aliasing problem without any syntactic additions.

But @craighurley you do raise an interesting possibility in pointing out the similarity between the AESR config and the aws-credentials-setup. My team supports software to manage the lifecycle of role assumption including role generation. We include support for AESR, and we're contemplating extending it to CLI operations. I'll take my questions on that to your own project's issues space, thanks!

[tilfin]

@rpattcorner I am releasing AESR v0.15.0 as another plugin v1 for AWS GovCloud and China partition. I don't have an environment to test the old UI anymore. It is a good effect to change the color of the V2 icon.

[rpattcorner]

@tilfin could you please say a little more? Are you saying we should use v1 for GovCloud and China partitions and V2 for commercial partition? Is there any way that v2 can support both (it appeared to support both partitions in the same limited way until v2.0.3). Is this because GovCloud is not receiving the new AWS console updates? It seemed to, in the sense that v0.15 broke in the same way.

Our back end tooling generates a single AESR configuration for users, and the AESR configuration uses the complex configuration with base accounts to allow role assumption in both commercial and in US GovCloud partitions. Users operate in both with a single AESR config and plugin. Are you saying we would now have to generate two configurations -- one for commercial, to be imported into v2.0.x and the other for govcloud to be imported into v0.15.0? That would make things much more complex -- for us, and more importantly more complex for the user who would have to import and manage two configurations.

I'm guessing I've misunderstood something here.

[tilfin]

@rpattcorner

Are you saying we should use v1 for GovCloud and China partitions and V2 for commercial partition?

Yes, temporarily.

Is there any way that v2 can support both (it appeared to support both partitions in the same limited way until v2.0.3).

There was an additional process for obtaining an alias and an switch state in 2.0.3, but that had not been tested in the old UI anymore. Therefore I removed the backward compatibility.

It seemed to, in the sense that v0.15 broke in the same way.

The reason seems that V2 is interfering to v0.15. You should deny the GovCloud domain from V2's Site access if you install V1.

manage two configurations.

You can paste the same generated configuration into V2 and V1(0.15) because GovCloud accounts and commercial ones are independent of each other.

[tilfin]

aws-extend-switch-roles_v1.zip SHA256: 444B95D6B6E4C60C6E914C76CB2CAFD7D1990882F55FDC8F06C6DF19BC57DC3F

[rpattcorner]

@tilfin thanks for the clarification!

I know you can't commit to anything but it would help if we could have some rough idea of when v2 might support US GovCloud as well as commercial. Are there real technical barriers, or is it just a matter of time and resources? The reason is that our own product supports AESR by machine-generating configs, and right now we generate a single config supporting multiple partitions.

We can change our code to generate two configs -- one config for V1/GovCloud and another config for V2/commercial -- but we'll just need to change the code back again and re-release when V2 supports all partitions, which will create a lot of confusion.

We're resource constrained too, but if there's something we can do to help, please let me know and I'll ask.

[tilfin]

@rpattcorner I heard GovCloud and China partition also be changed to the New UI some time.

I guess my English sentence was not good enough. You do not have to change generating code, one config could be used by both V1 and V2.

[rpattcorner]

@tilfin thanks for the quick reply and clarification. As for English, you can compare it to my Japanese and smile.

1. On a universal AESR,, do we need to wait for the new console rollout to use V2 for all partitions? Or, since V2 is partly independent of the amazon menu, will it be possible to drive both old and new console in a near future version?

2. On generating configs, I think we're saying that a single AESR config generated to handle two partitions via base accounts and source_profile will work fine in both V1 and V2, the idea being that V1 will show only the govcloud roles and V2 the commercial roles.

I've tried a two AESR version setup in a single browser with multiple tabs, one logged into commercial and the other logged into GovCloud, and there have been difficulties:

• v1 and v2 can exist in the same browser session, but ...
• v1 will continue to display role menus in the AWS menu, while v2 follows the new display in the extension menu
• v2 needs to be altered to ignore non-commercial partitions. I've attempted this using the setup below,

but v2 still attempts to display a menu on govcloud, and fails with the usual "The Console is not yet fully loaded." message. There's two errors in the extension page:

and

It's great that we can generate a single configuration, but I think we're going to need to require separate browsers (not just browser tabs) to work across partitions until v2 can support GovCloud too. Am I missing something important?

[tilfin]

@rpattcorner

1.

I am going to ask the AWS developers how long it take to release for GovCloud and China Partition. If it takes too long, I will consider it. Another problem is that the Chrome Web Store's review is also long.

2.

Yes exactly.

but v2 still attempts to display a menu on govcloud, and fails with the usual "The Console is not yet fully loaded." message. There's two errors in the extension page:

I guess that old errors remain before you change site access. You don't have to click the blue (V2) icon for GovCloud pages. In any case, those errors can be ignored and do not interfere with the operation in one browser.