On Windows, in the VSCode Terminal (which I believe is Powershell), I am attempting to work with the aws cli, and as part of that, I need to setup and refer to a profile that has credentials to connect to my AWS account. A month or so ago, I was using a profile named xxxx_AWSAdministratorAccess (where xxxx is my AWS account number), and all was working as expected. Today, I want to use different credentials, so I setup a new profile named CICD. If I set my profile using the aws configure command, it will work for that session. However if I create a new Terminal session, or start a new instance of VSCode, it reverts back to the xxxx_AWSAdministratorAccess profile.
I noticed in the Terminal there is an environment variable named AWS_PROFILE and this is set to xxxx_AWSAdministratorAccess. I have changed this using $env:AWS_PROFILE = 'CICD' as well as [System.Environment]::SetEnvironmentVariable('AWS_PROFILE','CICD'). Both work as they set the environment variable to CICD, and the latter command is supposed to persist the value according to what I read. It sort of works as I can open up a PowerShell session away from VSCode and it will also report the correct AWS profile, but as soon as I close the VSCode Terminal and re-open it reverts back to the xxxx_AWSAdministratorAccess value. It appears VSCode or an extension or something is caching this value, but I can't figure out where. Thoughts?
Per the comment from #rioV8 above, I opened a new Powershell window, set the AWS_PROFILE to CICD, and then launched VSCode from there. When I launched a new Terminal window inside VSCode, and ran dir env: the AWS_PROFILE variable was still set to CICD, so that is interesting. I then went to the Environment Variables in Control Panel and deleted AWS_PROFILE. I then re-launched VSCode and the environment variable is no longer there, and the aws configure command works as expected to update the profile.
So...long story short, I am not sure where that AWS_PROFILE environment variable came from, but deleting it as opposed to updating the value to something else, seems to have resolved my issue. Thanks for the suggestion!
Related
GCP Composer didn't apply new value in Environment Variables
As I have a connection string and put it under a new key in Environment Variables then save it. And after a while, I'd changed the host name in the connection id and save again, but this time the Composer still used the old config even though the Composer itself already stated that "This environment is running" which also means it finished the changing Environment Variables completely.
I already refreshed and checked for what I changed, the new value was there too. But running a new task with composer and it still used the old connection id.
There is no code that contain that connection id.
So weird, or I missed something.
This issue can be resolved by disabling and then enabling the Cloud Composer API.
Also, the AIRFLOW_GPL_UNIDECODE has to be set to yes.
I effectively have a credential leak in my dev environment and can't plug the hole.
Windows 10
Visual Studio Community 2017.
AWS Toolkit for Visual Studio... 1.16.0.0
aws-cli/1.17.15 Python/3.6.0 Windows/10 botocore/1.14.15
I am aware of single sign on but have never attempted to use it. Access Key/Secret Key only.
I started with the documented storage locations existing. Perhaps created in earlier versions of the cli and studio extension? I then manually deleted ~/.aws and the stumbled upon ~/appdata/local/awstoolkit but I can just keep firing off CLI commands and editing in studio as if nothing changed. Using the aws cli --no-sign-request switch or using some other computer demonstrates the normal disposition of my reference commands is to require my credentials.
I've closed and reopened terminals, studio. I rebooted. Nothing cached, didn't matter. With those credential folders still not present, I can uninstall the AWS CLI and AWS SDK, reinstall them and without additional steps dive back into CLI commands and studio work without providing keys.
The only functional means to delete local credentials is to delete my profile within AWS's studio extension. With credentials deleted in that way, stuff stops working as it should. Using the AWS CLI configure command the CLI and studio will both be able to do credentialed work again but somehow without creating ~/.aws or storing encrypted credentials in ~/appdata/local/awstoolkit. I can use the --debug switch with AWS CLI commands to see that when they do succeed that the tool claims it finds my shared credentials at ~/.aws.
While my credentials are working the expected files and folders do not exist. I cannot find the files or folders in Windows Explorer, PowerShell, or cmd.
What am I missing?
The paths you mentioned are the main relevant ones for files, at least if you are talking about CLI access (there are some other options within an application). The one other place to look is in your environment variables.
I would recommend creating a new set of credentials and disabling (not deleting) the old one. At a minimum you can start working with the new credentials and be aware of where you put them. Then, if something isn't working, you can enable the old credentials for long enough to do what you need to do with them before trying to locate them once again.
In Google shell which is a part of Google cloud, I set environment variable GOOGLE_APPLICATION_CREDENTIALS because It is need it for PHP NLP project [info: https://cloud.google.com/natural-language/docs/quickstart-client-libraries#client-libraries-install-php]. My project worked fine, but I notice that variable GOOGLE_APPLICATION_CREDENTIALS lasts on my sistem only one day. This is my third time that I am setting it. My project doesn't work when I am missing required variable. Am I doing something wrong?
EDIT:
It is default OS (Debian) when you create new App on Google App engine.
When I type help in Google shell I get info with:
Your 5GB home directory will persist across sessions, but the VM is ephemeral and will be reset
approximately 20 minutes after your session ends. No system-wide change will persist beyond that.
You are completely right, Cloud Shell is running on an ephemeral instance that resets some minutes after the session has ended, reason why you are losing the content of the environment variable you mentioned.
The documentation about limitations in Cloud Shell clearly states that it is intended for interactive use only, and any non-interactive session or intensive usage can be automatically terminated with (or without) a warning.
Therefore, and understanding from your question that you have a background script that is working with Cloud Natural Language, I would strongly advise you to move to a "real" instance of Compute Engine, in which you will have much more control about what is happening. This will allow more flexibility and you will be able to use a bigger machine type, given that Cloud Shell runs on a g1-small GCE instance which, in general, is not enough to run an application. Also, depending on your use case, you may even consider App Engine.
That being said, I have found that when constructing the LanguageClient instance, you may also not use Application Default Credentials and, instead, use the keyFile or keyFilePath variables (explained in the PHP Client Library reference) to pass the path to the JSON key directly to your code, instead of reading it from the environment variable.
Lets assume you are using Linux, make sure that:
The system is not being restarted, and if it is, make sure to set the environment variables accordingly (see how to set permantent environment variables)
I'm using AWS AppStream to stream a legacy .NET client. The app requires a parameter to start up correctly, which it gets via SessionContext passed into the create_streaming_url API call. I'd like to test this interaction locally without having to redeploy my app for every debug iteration as that takes well over half an hour. According to the AWS AppStream Docs session-context is stored in an environment variable that is only accessible via the AWS provided SessionContextRetriever.exe .NET application. The docs list the environment var as AppStream_Session_Context. I've tried setting this env var and running SessionContextRetriever.exe with no success. There is no documentation that I can find for SessionContextRetriever.exe but there's obviously something I'm missing here. Anybody have any experience with AppStream and session context?
The executable they provide doesn't come with a license, so I have to presume that it's copyrighted and licensed restrictively etc. So de-compiling it would be not be a good idea. But if somebody were to do such a thing, I would expect them to find something like
Console.Write(Environment.GetEnvironmentVariable("APPSTREAM_SESSION_CONTEXT", EnvironmentVariableTarget.Machine));
So I suggest that you try setting the environment variable at the system level for testing. That is, setting it in a script won't be visible to this executable because it's not looking at your current terminal session.
Setting the environment variable at the system level (using the Windows "Edit system environment variables) I see the output from this executable.
Run PS as Administrator:
PS C:\Users\Public\Apps> setx -m AppStream_Session_Context "Value"
PS C:\Users\Public\Apps> .\SessionContextRetriever.exe
Value
I remember being told to store AWS key into a bash**file (something named like that, can't remember exactly) for security reason, but now I forgot how to access that bash**file.
It should be ~/.bash_profile. Open a terminal window and type.
vi ~/.bash_profile.
To prevent committing sensitive application keys/data to your code, and to provide key access to programs, you should store app keys/sensitive information in environment variables. Environment variables are similar to variables in computer programs, except they exist system-wide in Linux and Windows.
In Linux, you can store those keys in the ~/.bash_profile, so they are available in the environment to command line programs.
nano ~/.bash_profile
in that file, add the following:
export AWS_ACCESS_KEY_ID= *ACCESS_KEY*
export AWS_SECRET_ACCESS_KEY= *SECRET_KEY*
Once saved, you’ll need to source it for the environment variable to work in your current session:
source ~/.bash_profile
In any new session, the environment variables will be loaded automatically.
Please note there are new and more preferred ways to store AWS credentials.
The AWS SDK team has recently made some changes that make it more
convenient, more consistent, and easier to specify credentials for the
SDKs in a more secure way.
Instead of keeping AWS credentials in environment variables, you can now put credentials into a single file that’s in a central location. The default location is this:
~/.aws/credentials (Linux/Mac)
See https://aws.amazon.com/blogs/security/a-new-and-standardized-way-to-manage-credentials-in-the-aws-sdks/