Feature: EdgeRC information from a vault

[brantpeery]

A feature for consideration: Get all the authentication information from a script level variable that was set from a vault or passed in from the calling application.

Use case:

When using Venafi Trust Protection Platform the administrator wants to update the certificates on the Akamai CPS through script. Venafi TPP can store and retrieve the credentials from it's secret store on any server that has the script installed. The Venafi TPP executable automatically starts a PowerShell process and passes the credentials to the script. The script uses the passed in credentials to invoke Akamai PowerShell commands.

Passing the credential could be as simple as giving a setter function like

New-AkamaiSession -ClientSecret "mysecret..." -Host "server" -AccessToken "Tokenasdfas" -ClientToken "tokenASDFads"

Which would set the $Script:AkamaiSession variable to the variable information or optionally return session variable containing the info. This script wide variable could be used by the Invoke-AkamaiRestMethod instead of the .edgerc file if the EdgeRCFile variable is intentionally left null. To make the process more flexible, the New-AkamaiSession function could use a -PassThrough that would not set the script scoped variable, but only return a new variable in the right format. Also a function Set-AkamaiSession could be used to switch session context with a variable containing the return of a New-AkamaiSession -Passthrough

New code to be introduced with change

• Function New-AkamaiSession
• Function Set-AkamaiSession
• Variable $Script:AkamaiSession

[stuartio]

Interesting suggestion! Might be easier to make the session function simply set environment variables, since this method is used a lot with other tools (e.g. Docker). This might interfere with users who assume subsequent functions are using .edgerc files but we could write a warning to the shell if that were the case. What do you think?

[brantpeery]

I hesitate to store anything in the registry that is not encrypted. It would be better to store in in the Credential store when in windows, and some other keyring in other OSes. As for the use of edgerc caching, I think that if the edgerc parameter is used it could override the use of the cached credentials. That way a person could include the edgerc file location only when they really wanted a refresh of the stored/cached credentials. Storing the creds may be overkill for this enhancement as the use case really only deals with being able to pass the creds in a parameter instead of using an edgerc file. Personally I don't like edgerc files because it stores the secret information in plain text for anyone with access to the file system to see. This often results in unintended access to the secrets. It is just bad security practice, no matter how many big companies use the pattern.

[brantpeery]

I have most of this already written. I can check it in an do a pull request if you agree that it would be a good enhancement.

[stuartio]

Sure, I'd be keen to see what you've designed. I will likely implement support for environment variables anyway, since it is in line with other Akamai tools we are developing, but there is no harm in additional methods. I could add support for specifying the host, access token, client token and client secret as parameters, but it would require editing all 600+ functions to support it, which is the only reason I am hesitant to do so.

[stuartio]

Can you rebase your PR please? I merged in some fairly large changes to the Invoke-AkamaiRestMethod function, though it shouldn't change your logic