Just thinking it might be a bit cleaner to store the alks.db file (and any future config files) under a dedicated hidden folder in the user's home dir instead of the home dir root.

I am trying to switch between roles to test some different IAM policies

I run alks sessions open -i -a "###/ALKSAdmin - foo" -r "Admin"
the I run alks sessions open -i -a "###/ALKSIAMAdmin - foo" -r "IAMAdmin"
notice the change from ALKSAdmin to ALKSIAMAdmin
and I get back the same set of keys

Its most likely caching at the account level and not taking the role into consideration.

Running alks sessions open -N does not force a new session as documented.

🍔  alks sessions open -N
ALKS v2.4.0
? Please select an ALKS account/role  2) 123123123/ALKS_PowerUser - foo :: IAM-AEP-PowerUserAccess
Resuming existing session in 123123123/ALKS_PowerUser - foo IAM-AEP-PowerUserAccess

alks iam deleterole is supposed to accept the account as an argument but ignores it.

$ alks iam deleterole -n "sagemaker-us-east-1" -a "$awsaepnp_admin"  -v
ALKS v2.17.0
[iam-delete]: validating role name: sagemaker-us-east-1
[iam-delete]: getting developer
[iam-delete]: getting password
[developer]: using password from keystore
[iam-delete]: getting accounts
[developer]: retreiving alks account

Would be nice if the selector defaulted to the last used account

Running the console subcommand is wiping out the developer configuration. Its a side effect of calling process.exit(1); which is needed for opn() to allow the CLI to exit. This is in keys and sessions.

Support syntax like alks developer switch 8423XXXXX/ALKS_PowerUser in the CLI. Should be fine to accept the entire account id/role string because users would likely put this in a shell alias anyway.

Or should we use the account index # like how alks sessions open <#> works?

This came from a request via Slack.

We'd like each ALKS client application to return information about its name and version to the ALKS API when executing requests. This information will be used to gather user information and gather insight to aid in troubleshooting. To standardize across technologies, we'd like this client to use the standard User-Agent header to specify its name and version (plus any additional useful information specific to the tool). See the RFC for more details on this
https://tools.ietf.org/html/rfc2616?spm=5176.doc32013.2.3.Aimyd7#section-3.8

Change Account to Developer to remove confusion between account and alks account. Check if anyone has multiple roles to an account, if not maybe we can drop references to role. Its such a long string with both.

Currently we're using prompt and inquire. Remove prompt and port all user inputs to use inquire.

Michael brought this one up, so wanted to stash the idea here.

The gist is to use the CLI to inform users when there's a new TF Provider out (for some period of time afterwards).

Right now it says bad API URL.

So when the -n flag is missing the CLI doesn't seem to provide a decent standard error message unless you are running in verbose mode. As far as I can tell even though the message is provided is very similar to what AWS would provide it is baked into the CLI.

A more descriptive error message should be put in place

Did following steps
alks developer configure
alks sessions open
Export AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY
But when i do echo $AWS_ACCESS_KEY_ID its blank.

1. First Env variables not getting set.
   2.Also session getting washed out in 10-15 min.
   These issue are pretty random. Does not get those on regular basic.
   I think it happening because Developer info getting washed out.

There might be an encoding/formatting issue when prop-ini modifies the AWS credentials file. One user reported an encoding issue and I found that it adds arbitrary spaces in the file and when using aws configure after ALKS modifies the file any new entries start at the end of the previous line - breaking the file.

When entering a password into alks developer configure, if it has a backslash, it will allow you to save and pick a default account, but will not work properly when trying to open a session afterwards. I was able to open a session when passing the -p flag and my password though.

If we fall back to .netrc we should be chmoding it so its only readable by the owner. We are currently doing this for the alks.db, just need to apply it to .netrc as well.

When file does not exist:

Error encountered during database keys transaction! Swallowing to preserve file integrity.
{ [Error: EEXIST: file already exists, mkdir '/Users/smuggla/.aws']
  errno: -17,
  code: 'EEXIST',
  syscall: 'mkdir',
  path: '/Users/smuggla/.aws' }

It seems that if the CLI throws an exception this wipes the database. Look into this, is it because we have it open and its not closing properly?

When a new key is requested, automatically add the key to the credentials file using the account alias and role as the profile.

For example,

[coxatlabs27-Admin]
aws_access_key_id=something
aws_secret_access_key=Something Else
aws_session_token=Some Long Stuff

Allow the user to specify if the environment variables and the [default] profile should not be updated; otherwise, update those by default as well.

Anytime a key is updated, perform the appropriate actions to the environment variables and the credentials file.

If users chooses No to "Save Password" during alks developer configure then we should wipe out any previously stored passwords.

For our Windows friends enable the option to toggle ALKS to output PowerShell environmental variables instead of CMD Prompt variables

it should be in the form of

$env:AWS_ACCESS_KEY_ID="{access-key}"
$env:AWS_SECRET_ACCESS_KEY= "{secret-key}"
$env:AWS_SESSION_TOKEN="{session-token}"
$env:AWS_DEFAULT_REGION="us-east-1"

On my Windows 10 machine, while executing "alks developer configure", and after I select default ALKS account/role I would receive a "Error saving developer" message in the console.

I downloaded the source and added console.error(err.message); to Developer.saveDeveloper callback if(err) block and got a more helpful "ENOENT: no such file or directory, open 'D:\Users\kjmil\alks.db'"

I created a "D:\Users\kjmil" directory and received a successful "Developer saved!" message.

This is the first time I have used ALKS-CLI so I'm not sure exactly what issue should be resolved, but I think I may be seeing a combination of possible issues:

1. ALKS-CLI probably wanted to use "C:\Users\kjmil" which does exist instead of "D:..."
2. Should ALKS-CLI create the directory if it doesn't exist?
3. I didn't dig deeper, but I'm not sure where utils.log(program, logger, 'error saving! ' + err.message); is writing to. Should a user have to dig deeper to find the log (or hack at the source like me) to view the err.message?

ALKS handles validation of business rules on the server side. Ping me for our blog posts on this subject if needed.

Role type is Cross Account
Need to pass a trustArn as well

It would be great if ALKS remembered which accounts you wanted to use, either by tracking which ones you use most or by adding "favorites". Often developers have a handful of accounts with a few roles each, which makes finding the correct role annoying.

If ALKS supported favoriting certain roles and put them at the top of the list, it would be much easier.

Bonus points for adding a flag to only show favorites in the CLI!

When running

$ alks developer accounts

would like an option to print those accounts in a clean CSV format. Something like

$ alks developer accounts -o csv

990000000099/ALKSReadOnly - awstest,ReadOnly,Standard

Providing a bad password crashes configure.

🍔  alks developer configure
ALKS v2.3.0
ALKS server:  (xxxxx) 
Network Username:  (xxxxx) 
Network Password:  *********

? Save password Yes
/usr/local/lib/node_modules/alks/bin/alks-developer-configure:93
            if(!accounts.length){
                        ^

TypeError: Cannot read property 'length' of undefined
    at /usr/local/lib/node_modules/alks/bin/alks-developer-configure:93:25
    at Request._callback (/usr/local/lib/node_modules/alks/node_modules/alks-node/lib/alks-api.js:142:20)
    at Request.self.callback (/usr/local/lib/node_modules/alks/node_modules/request/request.js:186:22)
    at emitTwo (events.js:87:13)
    at Request.emit (events.js:172:7)
    at Request.<anonymous> (/usr/local/lib/node_modules/alks/node_modules/request/request.js:1081:10)
    at emitOne (events.js:77:13)
    at Request.emit (events.js:169:7)
    at IncomingMessage.<anonymous> (/usr/local/lib/node_modules/alks/node_modules/request/request.js:1001:12)
    at IncomingMessage.g (events.js:260:16)

Account/role shortcutting isn't working on delete role. You have to supply both the account and the role. Should work like sessions commands and extract the role type from the account string.

The first time I used the command alks sessions open, I was prompted with all of my available accounts to choose from (I have 3 available to me at the portal when I am using a browser).

Now, whenever I use alks sessions open I am only able to choose a single account, the first one I ever chose.

If I run alks developer accounts I can see the 3 accounts available to me in the browser.

I tried uninstalling/reinstalling but did not have any luck.

Currently an incorrect password provided during alks developer configure returns the error message "Error configuring developer: Bad response received, please check API URL.".

The actual API call is returning the error message which we should be displaying:

{
  "errorMessage": "Authentication failed. Invalid username or password"
}

The links to https://github.com/Cox-Automotive/ALKS result in 404. Is that repo still available to the public?

Currently latest version of node can't find fsevents binary.

More details on Slack: https://coxauto.slack.com/archives/C4C5MKVQ9/p1552942215128600

From Bret Lowery:

I'm using the AWS and ALKS CLI on a PoC project. A Bash script on my EC2 instance makes this ALKS CLI call multiple times a day:
alks sessions open -a "912278622850/ALKSLabAdmin - awscoxautolabs62" -r "LabAdmin"

Normally it returns this to stdout:
Creating new session in 912278622850/ALKSLabAdmin - awscoxautolabs62 LabAdmin

But once a day, when I SSH into the instance for the first time and the CLI call happens for the first time that day, it sends this to stdout and stderr:
Creating new session in 912278622850/ALKSLabAdmin - awscoxautolabs62 LabAdmin
(node:5374) Warning: Use Cipheriv for counter mode of aes-256-ctr
(node:5374) Warning: Use Cipheriv for counter mode of aes-256-ctr
(node:5374) Warning: Use Cipheriv for counter mode of aes-256-ctr
(node:5374) Warning: Use Cipheriv for counter mode of aes-256-ctr
(node:5374) Warning: Use Cipheriv for counter mode of aes-256-ctr

If I call it again anytime that day it doesn't happen, but it does the following morning. I am getting ALKS keys/tokens with a 24hr expiration, if that has anything to do with it.

In all cases it seems to work normally. I get my session and subsequent AWS CLI calls with those keys/tokens in the env vars work, no problem.

Is this an error or do I need to do anything on my end to prevent this?

I liked being able to pick an account and have alks do operations on that account till I switched (since I rarely switch)

[11:40]
I have aliases set up for generating idea/env credentials based on the current account, it would get cumbersome to have an alias for each account

[11:40]
I’m fine with getting the account picker every time, too - it just doesn’t pipe nicely

[1143]
Maybe you can set a default during developer configure and then if you send --useDefault to sessions open it wont prompt.

alks developer set-default
alks sessions open --useDefault

I have tried the following on 3 different Windows environments and found the same issue. Not sure if I some different order needs to be done on Windows, but the same steps work on a Mac:

**alks developer configure**
      selected the account I want to use as power user
**alks sessions open -i -f -n**
      selected the IAM Admin session I want to use (basically the same account as above with IAM Admin)

Then tried any AWS CLI commands (aws iam list-roles, aws lambda list-functions, etc...)

I get the following error on all machines

A client error (IncompleteSignatureException) occurred when calling the ListFunctions operation: '/20170321/us-west-1/lambda/aws4_request' not a valid key=value pair (missing equal-sign) in Authorization header: 'AWS4-HMAC-SHA256 Credential=ASIAI6MS4VF2DKZT4E2A /20170321/us-west-1/lambda/aws4_request, SignedHeaders=host;x-amz-date;x-amz-security-token, Signature=bc3e0110fa58fcb2796433ba7634b341f21101c2034172b02de9dcdab3d8227b'.

If I go to the website, select keys for a session there, and set them as environment vars I am able to use the AWS CLI commands.

I had assumed you would only do profile outputs if you had installed the AWS CLI, but a few people have commented on the file missing error lately... I just need to create the dir/file (~/.aws/credentials) if it doesnt already exist when a user does a profile output.

Error adding new line!
{
   "errno": -2,
   "code": "ENOENT",
   "syscall": "open",
   "path": "/home/jkemp/.aws/credentials"
}

I was unable to run 'alks developer configure'. alks developer logout2fa fixed the issue. Posting for further debugging.

ddcwillb@~$ /Users/ddcwillb/.nvm/versions/node/v9.11.2/bin/alks developer configure -v
ALKS v3.0.1
[dev-config]: getting developer
? ALKS server https://alks.coxautoinc.com/rest
? Network Username ddcwillb
[dev-config]: getting existing auth
[developer]: checking for access token
[dev-config]: getting existing password
[dev-config]: getting password
[developer]: getting password from prompt
? Network Password [hidden]
? Save password Yes
[dev-config]: Getting ALKS accounts
[developer]: retreiving alks account
[developer]: using cached auth object
[api:injectAuth]: getting refresh token
Error configuring developer: Failed

If you try to export to the credentials file and the profile exists and you dont provide the force flag it wipes out the config.

🍔  alks sessions open -o creds -n test
ALKS v2.3.0
Resuming existing session in #####/ALKS_PowerUser - ###### IAM-AEP-PowerUserAccess
The test profile already exists in AWS credentials. Please pass -f to force overwrite.

brianantonelli in ~/Dev/ALKS-CLI on master*
🍔  alks sessions open -o creds -n test -f
ALKS v2.3.0
Error: ALKS CLI is not configured. Please run: alks developer configure

Would be a nice feature if we could modify the lib used for the account selection to pipe to stderr instead of stdout. Then you could wrap your session open in an eval and still see the prompts.

Would be nice to have an output option for the ALKS Terraform Provider's environmental variables

something like-o tfenv or -o tf to output ALKS_ACCESS_KEY_ID instead of AWS_ACCESS_KEY_ID from the -o env flag so that it is a little less work to use IAMAdmin and inherited credentials from AWS Roles with the ALKS TF provider.

Alternatively maybe a -t that would modify all output formats to be their ALKS counterpart.. you know for our Windows and Fishshell friends :)

https://github.com/Cox-Automotive/terraform-provider-alks#provider-configuration

Defaulting to Federated Sessions cause more issues than it solves. IAM Sessions should be the default functionality. This could be bundled with #105

I tried to open session and save the result to my ~/.aws/credentials file.
When complaining about already existing AWS credentials, the log message refers to an undefined profile rather than the default profile.

% alks sessions open -o creds
The undefined profile already exists in AWS credentials. Please pass -f to force overwrite.

Purely cosmetic issue. The complaint is valid and adding -f does correctly overwrite the credentials under the default profile.

If you run configure and already have a password saved we should reprompt - use it as the default value.

Just a Minor annoyance since I havn't used the CLI in months.

The format of the -r and -a options isn't obvious from help or readme.md. I tried copying from ALKS web gui and the list presented when you don't provide -r or -a. Neither worked and threw a no permissions error.

I figured it out by looking through the source code to see exactly what it wanted. Realized later that running alks developer accounts gave me the format needed. Seems so obvious now that the delimiter is :: but I can see this as a major frustration to a newbie (or someone like me who has been using the desktop app for too long).

Expected: copy and paste from the alks session open list into a command line option to eliminate the need for user input

Observed: Format of list doesn't match with command line option format

Suggested fixes:

• update documentation with an example
• create a single command line option with both role and account in single string that can be copy and pasted from the alks session open list

An ALKS server can support several different choices for session TTL. The alks-cli should also support choosing a specific TTL. Perhaps something like:

alks sessions open --iam --newSession -expires 12

• Should now be alks sessions list
• Shouldnt execute the sessions, just list them
• Should differentiate between IAM and non-IAM keys
• Update docs

Currently, the metadata server only supports running on a macOS. Updating this to get it running on Linux would be a great addition. Specifically Linux RedHat 7 Enterprise.

We've been warning about it being deprecated for months, buh-bye keys! 😢

Windows PowerShell
alks sessions open

In developer.js line 99: clortho.getFromKeychain(ALKS_USERID) an error is returned if the PowerShell user profile script writes to stdout/err (not sure which).

In my profile script, I had Start-SshAgent -Quiet which was writing Identity added: C:\Users\gdawson/.ssh/id_rsa (C:\Users\gdawson/.ssh/id_rsa). This is being caught as an error on line 109 (in devloper.js: exports.getPasswordFromKeystore).

Workaround: Don't output within profile script
Suggested: Would it be better to run the PowerShell command with no profile? Would require PR to clortho.

Example: (I added the gpfk>ipss>err log)

D:\git\openSource\alks-cli\node_modules\clortho [master ≡ +0 ~3 -0 !]> alks sessions open --verbose                                                                                                                         ALKS v3.0.3
[sessions-open]: getting developer
[sessions-open]: getting auth
[developer]: checking for access token
[developer]: no access token found, falling back to password
[developer]: gpfk>ipss>err: Error: Identity added: C:\Users\gdawson/.ssh/id_rsa (C:\Users\gdawson/.ssh/id_rsa)

[developer]: no password found, prompting user
[developer]: getting password from prompt
? Password [hidden] [input is hidden]