Access Key, etc still required for Storage access when using use_iam_profile

[pghalliday]

This might be a duplicate of #44 but I have found that when using the use_iam_profile option with the Storage API:

connection = Fog::Storage.new({
  :provider                 => 'AWS',
  :aws_access_key_id        => '',
  :aws_secret_access_key    => '',
  :use_iam_profile     => true
})

I still have to provide the access key id and secret access key (even if only as empty strings) or I get the following error:

ArgumentError: Missing required arguments: aws_access_key_id, aws_secret_access_key
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/fog-core-1.30.0/lib/fog/core/service.rb:244:in `validate_options'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/fog-core-1.30.0/lib/fog/core/service.rb:268:in `handle_settings'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/fog-core-1.30.0/lib/fog/core/service.rb:98:in `new'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/fog-core-1.30.0/lib/fog/storage.rb:25:in `new'
/opt/gitlab/embedded/service/gitlab-rails/lib/backup/manager.rb:46:in `upload'
/opt/gitlab/embedded/service/gitlab-rails/lib/backup/manager.rb:32:in `block in pack'
/opt/gitlab/embedded/service/gitlab-rails/lib/backup/manager.rb:13:in `chdir'
/opt/gitlab/embedded/service/gitlab-rails/lib/backup/manager.rb:13:in `pack'
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/backup.rake:16:in `block (3 levels) in <top (required)>'

You can see that I'm using version 1.3.0 of fog with Gitlab

This was confusing for a while...

[geemus]

@fcheung I've never actually used this feature myself, any chance you have some ideas or suggestions about what is going on here? I think if it worked it should fill those keys in before the check, but maybe I'm missing something.

[pghalliday]

It works fine. It's just odd that it requires the access key id and secret access key fields to be supplied (even though I just give it blank strings)

I think the problem is this line in storage.rb

      requires :aws_access_key_id, :aws_secret_access_key

these parameters should not be required if :use_iam_profile is specified. It's a minor issue as it doesn't block but it was a bit confusing for a while

[geemus]

Ah, that's good to know (but agreed it is weird). I guess maybe we expect that in many cases you would provide credentials in the first place and then use this to override them maybe? I think the require is ok, but it does need to happen in a particular order (ie the use_iam_profile part would need to be processed to get creds and THEN they would get checked). Guess maybe we aren't there presently though, not sure how hard it would be to fix, but at least with this we acknowledge it and maybe others can find this to help them understand.

[pghalliday]

yup, i think this is a useful note in case others run into the same problem

[fcheung]

That's weird - I use this all the time and have never needed the blank arguments (unless something has changed recently. )

[geemus]

@fcheung do you use it with ec2 commands or with s3? I was wondering if maybe there was something different between the two.

[fcheung]

I've used both - i've got stuff like

Fog::Storage.new(AwsCredentials['report_storage'])

litterally all over the codebase

where that credentials object returns something like

 {:use_iam_profile => true, :region => 'eu-west-1', :provider => 'AWS'}

The fetch_credentials method from the base service class is overriden to do the lookup so you shouldn't need blank strings any more than you would if you were loading them from .fog (validation happens after this see https://github.com/fog/fog-core/blob/master/lib/fog/core/service.rb#L268 )

[geemus]

Weird, thanks for the clarification.

[geemus]

@pghalliday maybe ensure you have latest versions of fog/fog-core/fog-aws? That said, I don't recall this changing any time recently.

[pghalliday]

@geemus I haven't checked the latest version, I ran into this while trying to configure gitlab which has all this stuff embedded so it's not trivial to update. If i can validate that this works correctly in the latest version, I'll raise an issue over on the gitlab project. Thanks

[geemus]

Sounds good, thanks!

[fgimian]

Sorry to comment on a closed issue, but this issue is still present as noted on my GitLab installation which uses fog 1.42.0.

Any help would be greatly appreciated

Cheers
Fotis

[stanhu]

We are using fog 1.4.0 in GitLab, and it appears the workaround to specify a blank access ID and key does work. I think #162 (comment) is spot on that these parameters should be optional if IAM profiles are being used:

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/rolename

Which would return:

{ 
"Code" : "Success", 
"LastUpdated" : "2017-08-17T18:23:14Z", 
"Type" : "AWS-HMAC", 
"AccessKeyId" : "AKIA***********", 
"SecretAccessKey" : "************", 
"Token" : "************", 
"Expiration" : "2017-08-18T00:32:58Z" 
}

[oyarzun]

@stanhu Sounds like you are you using GitLab 9.5.0. Gitlab 9.5.0 upgraded to fog-aws to 1.4.0. I've been using GitLab for a while with blank access ID and key and use_iam_profile true without problems, but after upgrading to 9.5.0 it stopped working.

Was there anything you had to change in your gitlab.rb?

[oyarzun]

Looks like blank access ID and key are no longer required with use_iam_profile set to true.

[stanhu]

@oyarzun Thanks, I think I was looking at the wrong version. GitLab 9.4 uses fog-aws 0.13.0, and it sounds like the upgrade to fog-aws 1.4.0 requires omitting blank values: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/13871

[bushev]

Guys,

How GitLab lookups for my s3 bucket without Key id?

I'm using GitLab 10.2.4. My config is:

gitlab_rails['backup_upload_connection'] = {
    'provider' => 'AWS',
    'region' => 'eu-central-1',
    'use_iam_profile': true
}
gitlab_rails['backup_upload_remote_directory'] = 'mb-gitlab'

Got error without aws_access_key_id and aws_secret_access_key:

Uploading backup archive to remote storage mb-gitlab ... [fog][WARNING] Unable to fetch credentials: connect_write timeout reached
rake aborted!
ArgumentError: Missing required arguments: aws_access_key_id, aws_secret_access_key
/opt/gitlab/embedded/service/gitlab-rails/lib/backup/manager.rb:174:in `connect_to_remote_directory'
/opt/gitlab/embedded/service/gitlab-rails/lib/backup/manager.rb:40:in `upload'
/opt/gitlab/embedded/service/gitlab-rails/lib/backup/manager.rb:27:in `block in pack'
/opt/gitlab/embedded/service/gitlab-rails/lib/backup/manager.rb:11:in `chdir'
/opt/gitlab/embedded/service/gitlab-rails/lib/backup/manager.rb:11:in `pack'
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/backup.rake:21:in `block (3 levels) in <top (required)>'
/opt/gitlab/embedded/bin/bundle:23:in `load'
/opt/gitlab/embedded/bin/bundle:23:in `<main>'
Tasks: TOP => gitlab:backup:create

Errors with aws_access_key_id and aws_secret_access_key:

Uploading backup archive to remote storage mb-gitlab ... [fog][WARNING] Unable to fetch credentials: connect_write timeout reached
[fog][WARNING] Unable to fetch credentials: connect_write timeout reached
[fog][WARNING] Unable to fetch credentials: connect_write timeout reached

I have attached the policy to IAM user:

Hot get it works? :-)

[geemus]

Unfortunately, I haven't done much with iam profiles (at least recently). @lanej any chance you are more current and could advise? Thanks!

[khalfanathman]

i had to go to delete a line in rake file to resolve this issue..../usr/local/rvm/gems/ruby-2.5.3/gems/rake-11.3.0/exe

[khalfanathman]

it was
Rake.application.run

[geemus]

@khalfanathman Thanks for the detail.