Loading EC2 user data into grailsApplication.config

[micke_]

Hi

I'm thinking about ways of providing config values (mainly aws secret and user keys and localization ) via ec2 "user data" that is picked up by a grails app during startup.

Since EC2 user data is accessed via a get call like :

GET http://169.254.169.254/latest/user-data

This returns whatever text you've configured, for example (or json etc.) :
key1=value1
key2=value2

What I'd like to do is hook something into the grails webapp startup which calls this URL using http builder or similar, parses out the key value pairs and puts them into the grailsApplication.config configuration so it can be used with my aws beans etc. just as if it was hard coded into Config.groovy.

What is the most convenient mechanism to fit this into the startup sequence/lifecycle? Not sure if the below works but they are what I've thought of so far:
- Config script which is added to config.locations
- class called from within Config.groovy like : new UrlConfigLoader("http://169.254.169.254/latest/user-data").populate(this)

Not sure if user data is the best way of providing these "server external" config values, so please let me know if there is a better way.

Cheers,
 Micke

[lucastex]

Best way to do this is export your credentials with user-data 

export AWS_ACCESS_KEY=xxxxxxxxxx

And get with system.getenv

[]s,

Lucas

On Sunday, June 24, 2012, Mikael Andersson wrote:

Hi

I'm thinking about ways of providing config values (mainly aws secret and user keys and localization ) via ec2 "user data" that is picked up by a grails app during startup.

Since EC2 user data is accessed via a get call like :

GET http://169.254.169.254/latest/user-data

This returns whatever text you've configured, for example (or json etc.) :
key1=value1
key2=value2

What I'd like to do is hook something into the grails webapp startup which calls this URL using http builder or similar, parses out the key value pairs and puts them into the grailsApplication.config configuration so it can be used with my aws beans etc. just as if it was hard coded into Config.groovy.

What is the most convenient mechanism to fit this into the startup sequence/lifecycle? Not sure if the below works but they are what I've thought of so far:
- Config script which is added to config.locations
- class called from within Config.groovy like : new UrlConfigLoader("http://169.254.169.254/latest/user-data").populate(this)

Not sure if user data is the best way of providing these "server external" config values, so please let me know if there is a better way.

Cheers,
 Micke

--

Lucas Teixeira

[micke_]

Do you mean from .profile or similar? If so that would mean that I would have to login to each machine and set this up.

What I like about user data is that it could be used to provide these config items externally to the server. I'm not using elastic beanstalk but if I do user data seems like a good way to go.

But do agree that .profile is the easiest solution and ec2 user data could be a bit of overkill.

cheers

On 25 June 2012 05:03, Lucas F. A. Teixeira <[hidden email]> wrote:

Best way to do this is export your credentials with user-data 

export AWS_ACCESS_KEY=xxxxxxxxxx

And get with system.getenv

[]s,

Lucas

On Sunday, June 24, 2012, Mikael Andersson wrote:

Hi

I'm thinking about ways of providing config values (mainly aws secret and user keys and localization ) via ec2 "user data" that is picked up by a grails app during startup.

Since EC2 user data is accessed via a get call like :

GET http://169.254.169.254/latest/user-data

This returns whatever text you've configured, for example (or json etc.) :
key1=value1
key2=value2

What I'd like to do is hook something into the grails webapp startup which calls this URL using http builder or similar, parses out the key value pairs and puts them into the grailsApplication.config configuration so it can be used with my aws beans etc. just as if it was hard coded into Config.groovy.

What is the most convenient mechanism to fit this into the startup sequence/lifecycle? Not sure if the below works but they are what I've thought of so far:
- Config script which is added to config.locations
- class called from within Config.groovy like : new UrlConfigLoader("http://169.254.169.254/latest/user-data").populate(this)

Not sure if user data is the best way of providing these "server external" config values, so please let me know if there is a better way.

Cheers,
 Micke

--

Lucas Teixeira

[kaaloo]

I like the idea of mapping this to config.  I currently use lazy properties like this for specific user data values :

@Lazy String instanceId = {new URL('<a href="http://169.254.169.254/latest/meta-data/instance-id&#39;).text}(">http://169.254.169.254/latest/meta-data/instance-id').text}()

Luis

On Sun, Jun 24, 2012 at 7:41 PM, Mikael Andersson <[hidden email]> wrote:

Hi

I'm thinking about ways of providing config values (mainly aws secret and user keys and localization ) via ec2 "user data" that is picked up by a grails app during startup.

Since EC2 user data is accessed via a get call like :

GET http://169.254.169.254/latest/user-data

This returns whatever text you've configured, for example (or json etc.) :
key1=value1
key2=value2

What I'd like to do is hook something into the grails webapp startup which calls this URL using http builder or similar, parses out the key value pairs and puts them into the grailsApplication.config configuration so it can be used with my aws beans etc. just as if it was hard coded into Config.groovy.

What is the most convenient mechanism to fit this into the startup sequence/lifecycle? Not sure if the below works but they are what I've thought of so far:
- Config script which is added to config.locations
- class called from within Config.groovy like : new UrlConfigLoader("http://169.254.169.254/latest/user-data").populate(this)

Not sure if user data is the best way of providing these "server external" config values, so please let me know if there is a better way.

Cheers,
 Micke

[jstell]

Just a friendly caveat: user-data is readable by all users on the instance. You might want to consider delivering this information in a more secure manner.

Jason

On Sun, Jun 24, 2012 at 11:03 PM, Lucas F. A. Teixeira <[hidden email]> wrote:

Best way to do this is export your credentials with user-data 

export AWS_ACCESS_KEY=xxxxxxxxxx

And get with system.getenv

[]s,

Lucas

On Sunday, June 24, 2012, Mikael Andersson wrote:

Hi

I'm thinking about ways of providing config values (mainly aws secret and user keys and localization ) via ec2 "user data" that is picked up by a grails app during startup.

Since EC2 user data is accessed via a get call like :

GET http://169.254.169.254/latest/user-data

This returns whatever text you've configured, for example (or json etc.) :
key1=value1
key2=value2

What I'd like to do is hook something into the grails webapp startup which calls this URL using http builder or similar, parses out the key value pairs and puts them into the grailsApplication.config configuration so it can be used with my aws beans etc. just as if it was hard coded into Config.groovy.

What is the most convenient mechanism to fit this into the startup sequence/lifecycle? Not sure if the below works but they are what I've thought of so far:
- Config script which is added to config.locations
- class called from within Config.groovy like : new UrlConfigLoader("http://169.254.169.254/latest/user-data").populate(this)

Not sure if user data is the best way of providing these "server external" config values, so please let me know if there is a better way.

Cheers,
 Micke

--

Lucas Teixeira

[Ian Roberts]

On 25/06/2012 14:27, Jason Stell wrote:
> Just a friendly caveat: user-data is readable by all users on the
> instance. You might want to consider delivering this information in a
> more secure manner.

This.

We use the AMIs provided by Ubuntu on EC2, and they have a tool called
cloud-init that allows you to put a special multipart MIME bundle into
the user data that will be downloaded early in the boot process and used
to provide configuration and startup scripts, etc.  Part of our bundle
looks like this:

Content-Type: multipart/mixed; boundary="===============0701744590=="
MIME-Version: 1.0

--===============0701744590==
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"

#cloud-config

disable_ec2_metadata: true

--===============0701744590==
Content-Type: text/cloud-boothook; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="write-config.sh"

#!/bin/bash

# Create a configuration file containing the AWS access keys and
# other runtime settings.

configfile=/etc/app-config.groovy

cat <<EOF > $configfile
myapp {
  aws {
    accessKeyId = '...'
    secretKey = '...'
  }
  // other config goes here
}
EOF

--===============0701744590==--

The first section is a cloud-init configuration file,
"disable_ec2_metadata: true" tells cloud-init to block access to the
metadata service at the iptables level.  This is important in our case
because the app is part of a system that allows users to run their own
code (suitably sandboxed) on our EC2 machines, and we don't want them to
be able to read our access keys from http://169.254.169.254/...

The second section is a "boothook" script that runs at the earliest
possible point in the boot process, and writes a configuration file to
/etc containing the relevant data.  The grails app includes
file:/etc/app-config.groovy as an external config file.  We actually go
further than this in our app and have a mechanism whereby the config
file overwrites itself once it has been read for the same reasons as above.

Ian

--
Ian Roberts               | Department of Computer Science
[hidden email]  | University of Sheffield, UK

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[micke_]

Thanks for the advice, will have to look into cloud-init!

Are there any security concerns relating to user-data if an instance is used solely by an app developed by myself which doesn't allow users to execute any groovy or otherwise arbitrary code ?
Simply slurping up user-data feels like a pretty simple and light weight solution if there aren't security issues preventing its use.

Thanks again,
 micke

On 25 June 2012 18:18, Ian Roberts <[hidden email]> wrote:

On 25/06/2012 14:27, Jason Stell wrote:
> Just a friendly caveat: user-data is readable by all users on the
> instance. You might want to consider delivering this information in a
> more secure manner.

This.

We use the AMIs provided by Ubuntu on EC2, and they have a tool called
cloud-init that allows you to put a special multipart MIME bundle into
the user data that will be downloaded early in the boot process and used
to provide configuration and startup scripts, etc.  Part of our bundle
looks like this:

Content-Type: multipart/mixed; boundary="===============0701744590=="
MIME-Version: 1.0

--===============0701744590==
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"

#cloud-config

disable_ec2_metadata: true

--===============0701744590==
Content-Type: text/cloud-boothook; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="write-config.sh"

#!/bin/bash

# Create a configuration file containing the AWS access keys and
# other runtime settings.

configfile=/etc/app-config.groovy

cat <<EOF > $configfile
myapp {
 aws {
   accessKeyId = '...'
   secretKey = '...'
 }
 // other config goes here
}
EOF

--===============0701744590==--

The first section is a cloud-init configuration file,
"disable_ec2_metadata: true" tells cloud-init to block access to the
metadata service at the iptables level.  This is important in our case
because the app is part of a system that allows users to run their own
code (suitably sandboxed) on our EC2 machines, and we don't want them to
be able to read our access keys from http://169.254.169.254/...

The second section is a "boothook" script that runs at the earliest
possible point in the boot process, and writes a configuration file to
/etc containing the relevant data.  The grails app includes
file:/etc/app-config.groovy as an external config file.  We actually go
further than this in our app and have a mechanism whereby the config
file overwrites itself once it has been read for the same reasons as above.

Ian

--
Ian Roberts               | Department of Computer Science
[hidden email]  | University of Sheffield, UK

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[kaaloo]

Nice!  Great post!  Didn't know about the disable_ec2_metadata. On the other hand, with the new IAM instance roles you really don't need access keys unless you're not using the aws sdk:

http://aws.typepad.com/aws/2012/06/iam-roles-for-ec2-instances-simplified-secure-access-to-aws-service-apis-from-ec2.html

Luis

On Mon, Jun 25, 2012 at 7:18 PM, Ian Roberts <[hidden email]> wrote:

On 25/06/2012 14:27, Jason Stell wrote:
> Just a friendly caveat: user-data is readable by all users on the
> instance. You might want to consider delivering this information in a
> more secure manner.

This.

We use the AMIs provided by Ubuntu on EC2, and they have a tool called
cloud-init that allows you to put a special multipart MIME bundle into
the user data that will be downloaded early in the boot process and used
to provide configuration and startup scripts, etc.  Part of our bundle
looks like this:

Content-Type: multipart/mixed; boundary="===============0701744590=="
MIME-Version: 1.0

--===============0701744590==
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"

#cloud-config

disable_ec2_metadata: true

--===============0701744590==
Content-Type: text/cloud-boothook; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="write-config.sh"

#!/bin/bash

# Create a configuration file containing the AWS access keys and
# other runtime settings.

configfile=/etc/app-config.groovy

cat <<EOF > $configfile
myapp {
 aws {
   accessKeyId = '...'
   secretKey = '...'
 }
 // other config goes here
}
EOF

--===============0701744590==--

The first section is a cloud-init configuration file,
"disable_ec2_metadata: true" tells cloud-init to block access to the
metadata service at the iptables level.  This is important in our case
because the app is part of a system that allows users to run their own
code (suitably sandboxed) on our EC2 machines, and we don't want them to
be able to read our access keys from http://169.254.169.254/...

The second section is a "boothook" script that runs at the earliest
possible point in the boot process, and writes a configuration file to
/etc containing the relevant data.  The grails app includes
file:/etc/app-config.groovy as an external config file.  We actually go
further than this in our app and have a mechanism whereby the config
file overwrites itself once it has been read for the same reasons as above.

Ian

--
Ian Roberts               | Department of Computer Science
[hidden email]  | University of Sheffield, UK

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[jstell]

Well, we've strayed off of Grails subject matter, but, FWIW, the instance roles functionality still uses metadata to pass access keys to the instance. Keys are rotated periodically, but still readable by users on the instance. Ian passed along a good tip about disable_ec2_metadata, but I expect it would render IAM instance roles useless.

The first precaution you should take is to generate an IAM account with only the privileges that are needed (e.g., only read a specific S3 bucket, only snapshot volumes, only send SES emails, etc). Then if the access keys for this account are compromised, the risk is lessened (someone can't terminate your instances, delete all your S3 objects, etc).

A more complicated way of passing sensitive information to the instance:

- put the information (viz., your api keys) in a S3 bucket

- generate expiring links to the information 

- wget the link in a user-data script, do appropriate chown/chmod on the retrieved files

The S3 link could expire in just a few minutes - long enough for the instance to start up and retrieve the data.

A while back, Shlomo Swidler did a great analysis of options for passing credentials over here: http://shlomoswidler.com/2009/08/how-to-keep-your-aws-credentials-on-ec2.html

Jason

On Tue, Jun 26, 2012 at 1:36 AM, Luis Arias <[hidden email]> wrote:

Nice!  Great post!  Didn't know about the disable_ec2_metadata. On the other hand, with the new IAM instance roles you really don't need access keys unless you're not using the aws sdk:

http://aws.typepad.com/aws/2012/06/iam-roles-for-ec2-instances-simplified-secure-access-to-aws-service-apis-from-ec2.html

Luis

On Mon, Jun 25, 2012 at 7:18 PM, Ian Roberts <[hidden email]> wrote:

On 25/06/2012 14:27, Jason Stell wrote:
> Just a friendly caveat: user-data is readable by all users on the
> instance. You might want to consider delivering this information in a
> more secure manner.

This.

We use the AMIs provided by Ubuntu on EC2, and they have a tool called
cloud-init that allows you to put a special multipart MIME bundle into
the user data that will be downloaded early in the boot process and used
to provide configuration and startup scripts, etc.  Part of our bundle
looks like this:

Content-Type: multipart/mixed; boundary="===============0701744590=="
MIME-Version: 1.0

--===============0701744590==
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"

#cloud-config

disable_ec2_metadata: true

--===============0701744590==
Content-Type: text/cloud-boothook; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="write-config.sh"

#!/bin/bash

# Create a configuration file containing the AWS access keys and
# other runtime settings.

configfile=/etc/app-config.groovy

cat <<EOF > $configfile
myapp {
 aws {
   accessKeyId = '...'
   secretKey = '...'
 }
 // other config goes here
}
EOF

--===============0701744590==--

The first section is a cloud-init configuration file,
"disable_ec2_metadata: true" tells cloud-init to block access to the
metadata service at the iptables level.  This is important in our case
because the app is part of a system that allows users to run their own
code (suitably sandboxed) on our EC2 machines, and we don't want them to
be able to read our access keys from http://169.254.169.254/...

The second section is a "boothook" script that runs at the earliest
possible point in the boot process, and writes a configuration file to
/etc containing the relevant data.  The grails app includes
file:/etc/app-config.groovy as an external config file.  We actually go
further than this in our app and have a mechanism whereby the config
file overwrites itself once it has been read for the same reasons as above.

Ian

--
Ian Roberts               | Department of Computer Science
[hidden email]  | University of Sheffield, UK

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email