Salt-Cloud - Best Way to Specify Multiple IAM_Profiles for minions?

[ninjada]

Reaching the point where I'd like to have a range of different IAM profiles applied to different ec2 instances that I deploy but I can't seem to find any info if you can specifically set this per instance eg. in the profile.

Can only seem to see the ability to set it in the providers conf eg. iam_profile: 'arn:aws:iam::etc' -- Is setting up multiple providers the best/only way to go?

[Ch3LL]

@ninjada thanks for the report.

You guys: @ryan-lane @eyj @tkwilliams @lomeroe do you have any ideas?

[ryan-lane]

I don't use salt-cloud, so I'm not sure.

The boto_ec2 state module supports this (https://docs.saltstack.com/en/develop/ref/states/all/salt.states.boto_ec2.html#salt.states.boto_ec2.instance_present), but ability to ec2 instance absent/present is only in the development version of SaltStack.

Otherwise, boto_asg has supported this since it was added to Salt (https://docs.saltstack.com/en/latest/ref/states/all/salt.states.boto_asg.html). Autoscale groups are superior to single instances in basically every way. You can define an ASG to have min/max/desired == 1, which is equivalent to a single ec2 instance.

The major downside of using the boto* modules rather than salt-cloud is that the boto* modules won't auto-register minions to the master.

[DanyC97]

i have the same use case using salt-cloud. @ryan-lane if you don't mind, may i ask why you not using salt-cloud over boto modules? Is it because you missing a specific feature or is the investment done on boto?

Thanks

[ryan-lane]

I'm talking about the boto_* state and execution modules for saltstack. It's a way more feature complete set of modules for aws. I really wish at some point that salt cloud used these modules directly and the docs were linked together.

i have the same use case using salt-cloud. @ryan-lane https://github.com/ryan-lane if you don't mind, may i ask why you not using salt-cloud over boto modules? Is it because you missing a specific feature or is the investment done on boto?

Thanks

— Reply to this email directly or view it on GitHub https://github.com/saltstack/salt/issues/28390#issuecomment-153330907.

[DanyC97]

@ryan-lane much thanks for your feedback. Would you be able to comment (based on your experience) what would someone gain/ lose by using salt-cloud vs boto_* modules?

currently i'm migrating from RAX to AWS and while is easier to just use salt-cloud/ salt master i think not using boto_* might be a miss opportunity however i am not able to say which one is/are

[ryan-lane]

I wrote most of the modules, so I'm a bit biased. You can actually use both salt-cloud and the boto_* modules, if you want.

The boto modules support lots of AWS products, like VPC, ELBs, EC2 instances, Autoscale groups (and launch configs), security groups, IAM users and roles, Route53, Cloudwatch, RDS, Elasticache, Datapipeline (very soon), DynamoDB, CloudFormation (not that I'd recommend cloud formation), KMS, SNS, and SQS.

salt-cloud only supports a small number of these things and not as extensively. The major benefit of salt-cloud is that it will automatically link your minion to your master when it starts. the boto_* modules can't do this.

[lomeroe]

It's been a while since I've used salt cloud, I stumbled upon Ryan's blog posts about how he was doing things in AWS with salt and I stole as much as I could and haven't looked back...

When I did use it, I used cloud.profile and the 'vm_overrides' kwarg to modify what was specified in the profile/providers...below is the cloud.profile snippet from my old "create instance" salt orchestrator

I apologize ahead of time for how nasty this is....

instance_setup: salt.function:

• name: cloud.profile
• tgt: salt-cloud-minion
• arg:
  • profile={{ instance_profile }}
  • names={{ salt'pillar.get' }}

  • - vm_overrides={ {% if salt'pillar.get' -%} 'image':'{{ salt'pillar.get' }}', {% elif cloud_provider == 'EC2' -%} 'image':'{{ ec2_instance_image }}', {% if instance_subnet -%} 'subnetid':'{{ instance_subnet }}', {% endif -%} {% endif -%} {% if salt'pillar.get' -%} 'size':'{{ salt'pillar.get' }}', {% endif -%} {% if salt'pillar.get' -%} 'location':'{{ salt'pillar.get' }}', {% endif -%} 'minion':{'grains':{ 'cloud_provider':'{{ cloud_provider }}', {% if roles -%} 'roles':[{% for role in roles -%} '{{ role }}', {% endfor -%} ], {% endif -%} {% if custom_grains -%} {% for key,val in custom_grains.iteritems() -%} {% if val is string -%} '{{ key }}':'{{ val }}', {% else -%} '{{ key }}':{{ val }}, {% endif -%} {% endfor -%} {% endif -%} },}, {% if cloud_provider == 'GCE' -%} {% elif cloud_provider == 'EC2' -%} {% if volumes -%} 'volumes':[{% for vol_info in volumes -%} {'size':{{ vol_info['SIZE'] }}, 'device':'/dev/xvd{{ "%c"|format(loop.index + 97) }}',}, {% endfor -%} ], {% endif -%} 'tag':{'SERVICE':'{{ salt'pillar.get' }}', 'ENVIRONMENT':'{{ salt'pillar.get' }}', 'FUNCTION':'{{ salt'pillar.get' }}',}, 'securitygroupid':['{{ secGrpMap[instance_subnet] }}', {% for sec_grp in security_groups -%} '{{ sec_grp }}', {% endfor -%} ], 'availability_zone':'{{ salt['pillar.get']('instance_az', salt['pillar.get']%28'instance_location'%29 ~) }}', 'ssh_username':'{{ amis[instance_os]['ssh_user'] }}', 'del_all_vols_on_destroy':True, {% if iam_profile != '' -%} 'iam_profile':'{{ iam_profile }}', {% endif -%} {% endif -%} }

[DanyC97]

@lomeroe, @ryan-lane much thanks for reply.

@ryan-lane you nearly convinced me i should go with a hybrid model of boto_ + salt-cloud. Are you aware of any examples of how i could mix the two ?

Much thanks

[ryan-lane]

boto_* modules are just state runs, so if you give any minion (including the master) the IAM permissions necessary to run the states, it'll just work. I actually have a masterless example here, if you're interested:

https://github.com/lyft/confidant/tree/master/salt

I don't have any examples of how to mix the two.

[syedaali]

I am using iam-profiles in /etc/salt/cloud.profiles.d/myprofile.conf:

ec2: provider: aws-ec2 image: ami-96e605a5 size: t1.micro tag: {'Roles': 'etl', 'Team': 'myteam'} iam_profile: 'arn:aws:iam::XXXXX:instance-profile/myprofile'

The instance is showing up in the AWS console as having the correct IAM profile. When I login to the instance and run 'aws' cli commands, they work without access key and secret key. However, when I use salt states to download from S3, I get an error:

Command 'aws s3 cp s3://aws-codedeploy-us-west-2/latest/install /home/ubuntu/ --region us-west-2\nchmod 755 /home/ubuntu/install\n/home/ubuntu/install auto\n' failed with return code: 127

2015-11-07 03:33:01,862 [salt.loaded.int.module.cmdmod][ERROR ][19556] stdout: A client error (Forbidden) occurred when calling the HeadObject operation: Forbidden

Not sure why I can download from my shell, but SaltStack cannot download from S3?

The IAM role policy that this instance has is:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "NotAction": "iam:", "Resource": "" } ] }

[lomeroe]

@syedaali are you trying to use cmdmod to run aws s3 or are you using the s3 salt module?

I use instance profiles/salt to access s3 via states and the module.run, for example:

s3_file_download: module.run:

• name: s3.get
• bucket: {{ s3_bucket }}
• path: {{ s3_file_path }}
• local_file: /myfile.tar.gz
• location: {{ region }}

[blbradley]

I came to this problem. Expected to do something like this:

iam_profile:
  - 'arn:aws:iam::123456:instance-profile/s3-bucket1-read'
  - 'arn:aws:iam::123456:instance-profile/s3-bucket2-read'

Is this what others would expect? An issues search shows that there is not work towards this. So, I could probably do it. Maybe add iam_profiles that expects a list and keep the singular iam_profile for backward compatibility.

Ping me and I could do this by next week!

[blarghmatey]

@blbradley That is exactly what I would expect to be able to do. It definitely seems confusing that there is such a disparity in the amount of functionality available between salt cloud and the state modules available for different providers.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.