How Do I Assign a Different Security Group To My Staging Env?

Skip to first unread message

Matt Payne

Jul 30, 2016, 12:23:05 PM7/30/16
to rubber

I'm running Rubber 3.2.2 and am trying to get an instance provisioned in my staging environment. As a part of this, I was wanting to put it into a different security group (staging_default). I've tried a couple of different things, but it continually puts it into the 'default' security group.

Here's the relevant portion of my rubber.yml (I thought that I could override assigned_security_groups for the specific environment):

    description: The default security group
      - source_group_name: default
        source_group_account: "#{}"
      - protocol: tcp
        from_port: 22
        to_port: 22
        source_ips: []
    description: The default staging security group
      - source_group_name: staging_default
        source_group_account: "#{}"
      - protocol: tcp
        from_port: 22
        to_port: 22
        source_ips: []

# OPTIONAL: The default security groups to create instances with
assigned_security_groups: [default]

# OPTIONAL: Automatically create security groups for each host and role
# EC2 Classic doesn't allow one to change what groups an instance belongs to after
# creation, so it's good to have some empty ones predefined.  EC2 with VPC, however,
# does allow changing security groups after instance creation and allows far fewer
# security groups per instance, so you shouldn't enable this setting if using VPC.
auto_security_groups: false

# OPTIONAL: Automatically isolate security groups for each appname/environment
# by mangling their names to be appname_env_groupname
# This makes it safer to have staging and production coexist on the same EC2
# account, or even multiple apps.  NB: due to the security group limits per instance
# in EC2 with VPCs, this option should only be enabled if you're using EC2 Classic.
isolate_security_groups: false

# OPTIONAL: Prompts one to sync security group rules when the ones in amazon
# differ from those in rubber
prompt_for_security_group_sync: true

# OPTIONAL: A list of CIDR address blocks that represent private networks for your cluster.
# Set this to open up wide access to hosts in your network.  Consequently, setting the CIDR block
# to anything other than a private, unroutable block would be a massive security hole.
private_networks: []

# OPTIONAL: The packages to install on all instances
# You can install a specific version of a package by using a sub-array of pkg, version
# For example, packages: [[rake, 0.7.1], irb]
packages: [postfix, build-essential, git-core, libxslt-dev, ntp]

# OPTIONAL: The command used to identify your particular OS version.  This will be used for configurations
# in Rubber templates that are parameterized by OS version (e.g., package lists).  If not specified, Ubuntu
# will be assumed.
os_version_cmd: 'lsb_release -sr'

# OPTIONAL: gem sources to setup for rubygems
# gemsources: [""]

# OPTIONAL: The gems to install on all instances
# You can install a specific version of a gem by using a sub-array of gem, version
# For example, gem: [[rails, 2.2.2], open4, aws-s3]
gems: [open4, aws-s3, bundler, [rubber, "#{Rubber.version}"]]

# OPTIONAL: A string prepended to shell command strings that cause multi
# statement shell commands to fail fast.  You may need to comment this out
# on some platforms, but it works for me on linux/osx with a bash shell
stop_on_error_cmd: "function error_exit { exit 99; }; trap error_exit ERR"

# OPTIONAL: The default set of roles to use when creating a staging instance
# with "cap rubber:create_staging".  By default this uses all the known roles,
# excluding slave roles, but this is not always desired for staging, so you can
# specify a different set here
# staging_roles: "web,app,db:primary=true"
# Auto detect staging roles
staging_roles: "web,app,db:primary=true,memcached,sidekiq,redis_master,postgresql,postgresql_master"

    packages: [imagemagick]

    assigned_security_groups: [staging_default]

Any help would be greatly appreciated.


Kevin Menard

Aug 11, 2016, 3:41:23 PM8/11/16
Hi Matt,

I usually use the isolate_security_groups feature for this. Since your rules are essentially the same, is there a problem with having the "default" group?

You received this message because you are subscribed to the Google Groups "rubber" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
For more options, visit

Matt Payne

Aug 20, 2016, 10:00:52 AM8/20/16
to rubber
Hi Kevin,

Sorry for the delayed reply. I'll give that a shot.


Kevin Menard

Sep 4, 2016, 11:08:44 PM9/4/16
Hi Matt,

How did that work out?

Reply all
Reply to author
0 new messages