~/.aws/config and credentials files are missing in a previously working setup (Cloud9) of Jenkins and terraform

0

hi All Has anyone seen this issue. I don't know if it is related to Cloud9 or terraform or Jenkins, but the setup was working fine and the only changes that were made were to the Jenkinsfile (no terraform config file changes). And the Jenkinsfile change was trivial.

Both the .aws config and credentials files are completely missing now thus terraform cannot run.

======

I was making no changes to providers.tf file when this happened just the Jenkinsfile and the jenkinsfile is using AWS_SHARED_CREDENTIALS_FILE=‘/home/ubuntu/.aws/credentials’ as ENV variable.

Plan: 2 to add, 0 to change, 0 to destroy.

Error: configuring Terraform AWS Provider: no valid credential sources for Terraform AWS Provider found.

Please see Terraform Registry for more information about providing credentials.

AWS Error: failed to refresh cached credentials, no EC2 IMDS role found, operation error ec2imds: GetMetadata, http response error StatusCode: 404, request to EC2 IMDS failed

with provider[“Terraform Registry”], on providers.tf line 13, in provider “aws”: 13: provider “aws” {

========== this is without Jenkins

dave:~/environment/mtc-terraform-ansible-jenkins (dev_terraform_FULL_ansible) $ terraform plan

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:

create Terraform planned the following actions, but then encountered a problem:

random_id.mtc_compute_node_id[0] will be created resource “random_id” “mtc_compute_node_id” { b64_std = (known after apply) b64_url = (known after apply) byte_length = 2 dec = (known after apply) hex = (known after apply) id = (known after apply) } random_id.random will be created resource “random_id” “random” { b64_std = (known after apply) b64_url = (known after apply) byte_length = 2 dec = (known after apply) hex = (known after apply) id = (known after apply) } Plan: 2 to add, 0 to change, 0 to destroy. ╷ │ Error: configuring Terraform AWS Provider: no valid credential sources for Terraform AWS Provider found. │ │ Please see Terraform Registry │ for more information about providing credentials. │ │ AWS Error: failed to refresh cached credentials, no EC2 IMDS role found, operation error ec2imds: GetMetadata, http response error StatusCode: 404, request to EC2 IMDS failed │ │ │ with provider[“Terraform Registry”], │ on providers.tf line 13, in provider “aws”: │ 13: provider “aws” {

========== My providers.tf does use the shared_credentials_files

provider “aws” { region = “us-west-1”

shared_credentials_files=[“/home/ubuntu/.aws/credentials”] }

======

dave:~/environment $ aws configure list Name Value Type Location


profile None None access_key None None secret_key None None region None None

=====

I see that I can re-generate the files according to this link. https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html

I don't know if Cloud9 uses SSO, legacy SSO or short term (with token) when it set this up I did find a copy of the file in my notes (see below) and it looks like it is using short term (with token)

"Setting new configuration and credentials command examples" Example:

$ aws configure AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY Default region name [None]: us-west-2 Default output format [None]: json $ aws configure set aws_session_token fcZib3JpZ2luX2IQoJb3JpZ2luX2IQoJb3JpZ2luX2IQoJb3JpZ2luX2IQoJb3JpZVERYLONGSTRINGEXAMPLE

=====

this link explains how to configure the short term authentication manually

https://docs.aws.amazon.com/cli/latest/userguide/cli-authentication-short-term.html https://docs.aws.amazon.com/singlesignon/latest/userguide/howtogetcredentials.html

Does Cloud9 have a recovery mode where you can automatically have it regenerate the credentials and config files like it should be doing?

=======

I found a copy of the file in my notes. The top part indicates if this file is deleted that it will be generated again. Why is this file not being re-generated?

This is the top part of the file

==============

Do not modify this file, if this file is modified it will not be updated. If the file is deleted, it will be recreated on Wed Aug 09 2023 23:02:56 GMT+0000 (Coordinated Universal Time).

04c0a1d6304f4bc809013fdbb64a2836048819dcd96a9101ec06d40d1d64fc2a

================

below that is shown below (I relplaced the key id, secret key, and token with xx's but I have all the original keys, etc. I know the session Id is ephemeral so that will change. Will the key_id and secret_access_key be the same?

===================

[default] aws_access_key_id=<xxxxxxxxx> aws_secret_access_key=<xxxxxx> aws_session_token=<xxxxx>

===================

My guess is that the terraform access or the Jenkins access (via the providers.tf) to the file perhaps corrupted it? I don't know.

======

I resolved this issue (at least for now). I still do not know why or how the credentials file got deleted but AWS Cloud9 will disable this function if there is a new user added to access Cloud9 Environment until the owner of the env approves the user. Then the owner can re-enable it. When Cloud9 disables the function the file will be removed/deleted. I did not add any new users for accessibility but I am guessing that the Jenkins access via the shared credentials file in providers.tf and/or the explicit AWS_SHARED_CREDENTIALS_FILE Env variable in the Jenkinsfile spooked the Cloud9 into disabling it ?????

It was disabled when I pulled up the Cloud9 env preferences.

To re-enable it use this url as a resource

https://docs.aws.amazon.com/cloud9/latest/user-guide/security-iam.html#temporary-managed-credentials-control

Here is the relevant info:

"• If the AWS managed temporary credentials setting is set to off, whenever you turn it back on. (To view or change this setting, choose AWS Cloud9, Preferences in the menu bar of the IDE. On the Preferences tab, in the navigation pane, choose AWS Settings, Credentials.)"

the same can be done via the API as well.

warmest regards Dave

asked 8 months ago114 views
No Answers

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions