CloudFormation template to create CodeDeploy application

The requirement is to use cloudformation stacks to create CodeDeploy application and deployment group with required configuration. Although we get the information about which resources to use its all bits and pieces. It took me couple of hours to understand and write the CloudFormation template and use it to create codedeploy application.

Basically we have to create two cloudformation stacks.
1. stack1 – to create codedeploy application
2. stack2 – to create deployment group and other parameters and associate it with the codedeploy application created.
The AWS::CodeDeploy::Application resource creates an AWS CodeDeploy application. You can use the AWS::CodeDeploy::DeploymentGroup resource to associate the application with an AWS CodeDeploy deployment group.
stack1 – codedeploy-appName.json
creates codedeploy application
 
stack2 – codedeploy-deployGrp.json
associates with codedeploy application, creates deployment group, deployment config name, adds ec2 tag filters and ServiceRoleArn
Below is the template
codedploy-appName.json
{
“AWSTemplateFormatVersion”: “2010-09-09”,

“Resources”: {
“MyCodeDeployApp”: {
“Type” : “AWS::CodeDeploy::Application”,
“Properties” : {
“ApplicationName” : “App11”
}
}
}
}

codedploy-deployGrp.json
{
“AWSTemplateFormatVersion”: “2010-09-09”,

“Parameters”: {
“DeploymentConfigurationName”: {
“Description”: “With predefined configurations, you can deploy application revisions to one instance at a time, half of the instances at a time, or all the instances at once.”,
“Type”: “String”,
“Default”: “CodeDeployDefault.OneAtATime”,
“ConstraintDescription”: “Must be a valid Deployment configuration name”
}
},

“Resources”: {
“MyCodeDeploy” : {
“Type” : “AWS::CodeDeploy::DeploymentGroup”,
“Properties” : {
“ApplicationName” : “App11”,
“DeploymentConfigName” : {
“Ref”: “DeploymentConfigurationName”
},
“DeploymentGroupName” : “DeployGrp11”,
“Ec2TagFilters” : [{
“Key” : “Name”,
“Type” : “KEY_AND_VALUE”,
“Value” : “App1-env”
}],
“ServiceRoleArn” : “arn:aws:iam::322340642362:role/deployRole”
}
}
}
}

Access control for S3

Do you want to control the access options for your S3 buckets and the objects in them ?

Amazon Simple Storage Service (S3) is storage for the Internet.

There are different types of access control for S3 bucket and objects in it.

Below are the possible options

  1. We can use Bucket policy to
  • Grant access to bucket (to view/list the objects in bucket)
  • Grant access to view/access the content of object in a bucket.
  • Grant access to edit the access control list for the bucket.

 

  1. We can use use IAM policy to grant access to S3 console to only view/list the buckets and objects inside them. (Note: they will not be able to access the data of an object)
  • AmazonS3FullAccess
  • AmazonS3ReadOnlyAccess

           Custom IAM policy to

  • Grant access to bucket (to view/list the objects in bucket)
  • Grant access to view/access the content of object in a bucket.

 

  1. Provide Public access
  • Grant access to view/access the content of object in a bucket.
  • Grant access to edit the access control list for the bucket.

 

  1. Pre-signed URLs can be used to provide a URL that your users can employ to upload files with predefined names, as well as granting time-limited permission to download objects or list the contents of a bucket.

The pre-signed URLs are useful if you want your user/customer to be able upload a specific object to your bucket, but you don’t require them to have AWS security credentials or permissions.

This provides your users with limited access to a specific resource, removing the need to grant public access to your bucket.

When you create a pre-signed URL, you must provide your security credentials, specify a bucket name, an object key, an HTTP method (PUT for uploading objects), and an expiration date and time. The pre-signed URLs are valid only for the specified duration.

Do you want to setup Multi Factor authentication (MFA) for EC2

Last week I came across enabling Multi Factor Authentication for EC2 instances, so there will be extra level of verification code need to provided along with password to authenticate and login into EC2 instances. When I tried to implement this the information was spread across multiple blogs and the google authenticator link was not working as the blogs were all updated in the past.

It took me 2 hours to finally put all the bits together and activate the authentication.

Below are the steps I followed to implement MFA authentication successfully.

My assumption is that you already have a EC2 instance created. If so then Login into it and switch to root.

Then install the pam-devel, make, gcc-c++ and wget packages.

Linux uses PAM (Pluggable Authentication Module) to integrate the Google Authenticator MFA. So make sure that PAM and PAM-Devel packages are installed on your system.

[ec2-user@ip-192-26-10-97 ~]$ sudo su –

 [root@ip-192-26-10-97 ~]# yum install pam-devel make gcc-c++ wget

Loaded plugins: priorities, update-motd, upgrade-helper

amzn-main/latest                                         | 2.1 kB     00:00

amzn-updates/latest                                      | 2.3 kB     00:00

Package 1:make-3.82-21.10.amzn1.x86_64 already installed and latest version

Package wget-1.18-1.18.amzn1.x86_64 already installed and latest version

Resolving Dependencies

Dependency Updated:

glibc.x86_64 0:2.17-157.169.amzn1   glibc-common.x86_64 0:2.17-157.169.amzn1

Complete!

[root@ip-192-26-10-97 ~]#

Download the google authenticator source file using wget and install it

Download location: http://www.filewatcher.com/m/libpam-google-authenticator-1.0-source.tar.bz2.32708-0.html

[root@ip-192-26-10-97 ~]# wget ftp://ftp.netbsd.org/pub/pkgsrc/distfiles/libpam-google-authenticator-1.0-source.tar.bz2

--2017-03-01 10:15:55--  ftp://ftp.netbsd.org/pub/pkgsrc/distfiles/libpam-google-authenticator-1.0-source.tar.bz2

=> ‘libpam-google-authenticator-1.0-source.tar.bz2’

Resolving ftp.netbsd.org (ftp.netbsd.org)... 199.233.217.201, 2001:470:a085:999::21

Connecting to ftp.netbsd.org (ftp.netbsd.org)|199.233.217.201|:21... connected.

Logging in as anonymous ... Logged in!

==> SYST ... done.    ==> PWD ... done.

==> TYPE I ... done.  ==> CWD (1) /pub/pkgsrc/distfiles ... done.

==> SIZE libpam-google-authenticator-1.0-source.tar.bz2 ... 32708

==> PASV ... done.    ==> RETR libpam-google-authenticator-1.0-source.tar.bz2 ... done.

Length: 32708 (32K) (unauthoritative)

libpam-google-authenticator-1.0-source. 100%[============================================================================>]  31.94K  37.2KB/s    in 0.9s

2017-03-01 10:16:00 (37.2 KB/s) - ‘libpam-google-authenticator-1.0-source.tar.bz2’ saved [32708]

[root@ip-172-31-24-97 ~]#

Extract the downloaded file and install it using below command

tar -xvf libpam-google-authenticator-1.0-source.tar.bz2

cd libpam-google-authenticator-1.0

make

make install

If you want more information as what these commands does refer: https://robots.thoughtbot.com/the-magic-behind-configure-make-make-install

Make changes to the PAM and SSH configuration files to enable the Multi-Factor Authentication over SSH logins. Add below line to file /etc/pam.d/sshd

auth       required     pam_google_authenticator.so

In /etc/ssh/sshd_config, change the two parameters to yes and save it

PasswordAuthentication yes

ChallengeResponseAuthentication yes

Restart the sshd service

/etc/init.d/sshd restart

 

Next relogin again into EC2 instance

Add new user to the group

[root@ip-192-26-10-97 ~]# sudo useradd -s /bin/bash -m -d /home/testuser1 -g root testuser1

Change password of the new user

[ec2-user@ip-192-26-10-97 ~]$ sudo passwd testuser1

Changing password for user testuser1.

New password:

Retype new password:

passwd: all authentication tokens updated successfully.

[ec2-user@ip-192-26-10-97 ~]$

Add user to sudoers file by using command sudo visudo

testuser1  ALL=(ALL:ALL) ALL

Restart the sshd service

/etc/init.d/sshd restart

So now we have the new user created, you can try to login using the user credentials and you will prompted for password only.

Next you will have to switch to the new user and enable MFA for this user by giving command as google-authenticator

[root@ip-192-26-10-97 ~]# su - testuser1

[testuser1@ip-192-26-10-97 ~]$ google-authenticator

Do you want authentication tokens to be time-based (y/n) y

https://www.google.com/chart?chs=200x200&chld=M|0&cht=yr&nnhl=otpauth://totp/testuser1@ip-172-31-24-97%3Fsecret%3DXGR5RZHUEE7CIOXN

Your new secret key is: XGR8RXHUQQ7CROZN

Your verification code is 533145

Your emergency scratch codes are:

14262591

48294949

18396552

85439789

17308009

Do you want me to update your "/home/testuser1/.google_authenticator" file (y/n) y


Do you want to disallow multiple uses of the same authentication

token? This restricts you to one login about every 30s, but it increases

your chances to notice or even prevent man-in-the-middle attacks (y/n) y


By default, tokens are good for 30 seconds and in order to compensate for

possible time-skew between the client and the server, we allow an extra

token before and after the current time. If you experience problems with poor

time synchronization, you can increase the window from its default

size of 1:30min to about 4min. Do you want to do so (y/n) y


If the computer that you are logging into isn't hardened against brute-force

login attempts, you can enable rate-limiting for the authentication module.

By default, this limits attackers to no more than 3 login attempts every 30s.

Do you want to enable rate-limiting (y/n) y

[testuser1@ip-192-26-10-97 ~]$

So now we have the MFA enabled for our required user.

Next download the google-authenticator app on your android or IOS mobile and give the account name as

testuser1@

enter the secret key which gets generated when you run the google-authenticator command. Voila!! you should now see a verification code.

Login to EC2 instance using new user credentials and it will ask for verification code.