DEV Community: Durga Prasad Katrapally

Security best practices on AWS

Durga Prasad Katrapally — Mon, 14 Sep 2020 12:34:23 +0000

Security is real key thing in any environment and especially on Cloud.In this post I want to put few things that are really essential ( bare minimum ) to keep your AWS environment secure.

Root Access:

Always limit root access only to user creation and billing. It should not be used to create any resources or to perform any other operations on resources.

Implement MFA for root and all users. This will ensure that even if credentials are leaked the other form of authentication is still needed.

Principle of least privilege:

Any resource/role/user should never be given elevated access privileges than required. Always ensure only the required permissions only are granted not more. This will limit the blast radius just in case if there is a compromise in any credentials for any users.

Roles

Always try to use roles where ever possible as roles get temporary tokens to get to a service and they can be revoked if needed.

Services : IAM , Roles

Log everything:

Always log all API calls on all accounts. Use Cloud trail to log all logs to central security account or other and encrypt the logs to implement data integrity.

Logs provide key information in case of any security incident and play a key role in planning risk mitigation. So having all logs in a central location with only limited authorized access ( preferably read only ) will really help in getting to the core of security incident.

Services in AWS : Cloud Trail and S3

Encryption:

It is always best practice to have encryption at rest with all the sensitive data in cloud. AWS has several options depending on where you store the data.

Services : KMS , Cloud HSM , Own keys

Record changes:

It is always recommended to have a record of all changes that happen in any environment. AWS has Config service that allows to assess, audit, and evaluate the configurations of your AWS resources.

AWS config integrates with Cloud watch where cloud based event rules can be configured to notify any changes.

Services : AWS Config , Cloud watch, SNS

Automate security responses:

The challenge with security compromise is that there is no time on when a security event occurs. Always find ways to automate the security response so the risk of a compromise can be limited.

Use services such as Cloud watch events to trigger event based actions to Lambda so that as soon as something unexpected happens the response is all automated

Services : Cloud watch, Lambda, SNS

Patch regularly:

While there are many managed services on AWS, if your setup has any of the EC2 instances it is always advised to have all of them patched regularly. AWS handles security of the Hypervisor NOT the OS that you use. Understanding this is key in having secure environment for EC2.

Services such as AWS inspector will really help to getting the vulnerability reports for EC2 and AWS patch manager can be leveraged to automate patch cycles.

Services : Patch manager, AWS Inspector

Other key security products:

ACM , AWS Guard duty, AWS shield , AWS WAF are few of the other products for protection against Layer 3/4 and 7 attacks.

Conclusion:

Security is really vast topic and there are many things that still need to implemented depending on where a given environment stands. These are just minimal things that are needed to keep things secure at a very high level.

It is highly recommended to check the AWS security white paper which covers in depth on all aspects.

Top 5 reasons to consider cloud storage as an alternative to traditional on premise storage

Durga Prasad Katrapally — Tue, 08 Sep 2020 11:42:04 +0000

Storage is the most the valued component in Infrastructure and often companies end up spending lot for deploying and maintaining on-prem storage.

There are other over heads of maintaining RPO/RTO on storage, patching etc when leveraging on-prem storage.

With cloud emerging so fast and rapid, there are many key offerings on Cloud that would drive any organization to use cloud. Here are the top 5:

Costs:

Cloud storage is cheap compared to on-prem. The costs including maintenance, power are the direct savings that any organization would benefit. On top of this, all cloud service offer pay per use model which allow organization to pay only to what they use.

Organizations can also leverage cloud as a “ Disaster Recovery” strategy where they can move/replicate their production data loads for DR purposes. This strategy is much cheaper compared to having an exact DR strategy on another on premises Data Center.

Scalability:

One of the pain points of Data Center based storage solutions exists in the fact that scaling the existing storage. Storage projections may or may not match the actual usage. Sometimes companies end up spending more thinking of “buffer” for future. Cloud provides great scalability where organizations do not need to worry on data growth patterns.

Durability:

Cloud providers in general offer a great level of durability on the data that is stored in cloud. AWS for that matter offers 99.99999999999 ( 11 9’s ) durability which means that there is a chance of losing one file in roughly 659000 years.

Ease of access:

One of the greatest advantages of the having data on cloud is ease of access, with a simple internet connection and proper authentication/authorization one can access data from anywhere. ( There are certain intricacies on how data on cloud is managed like how/who/what can access data and how to securely access storage which I’m not touching here. Security is broader topic and any component on cloud should be tightly coupled with proper security to avoid data going to wrong hands. )

Storage independence:

On traditional Data center based storage, there are always conversation on a given make/model/vendor is not supported after sometime and there has to be a move to a better model, this is continuous process. This is always pain process. With Cloud, organizations need not worry on who is the storage vendor/what model and when will their end of life approach as this will be the responsibility of Cloud provider. This is very big leverage for any organization which allow them to focus on how to organize their data, how to use that data.

Conclusion:

In conclusion there are many aspects that drive any organization to move to cloud storage. The points discussed above are some of the key areas with are most beneficial to any organization. However, there are certain aspects like Compliance, Data Management, Security and Bandwidth limitations which are the anti patterns to cloud. One has to balance every aspect and make a move to use cloud storage to get the most out of it.

How did I re-architect my web application to serve dynamic forms serverless

Durga Prasad Katrapally — Mon, 31 Aug 2020 13:06:43 +0000

This use case is useful for the "contact us" or " feedback" section for most of the websites. Instead of having the entire website running on web server and supporting DB, the proposed architecture really helps to have the same functionality without having to manage any servers.

I want to touch on how I changed existing setup for my Web application that typically had my web portfolio on it. Web site has fairly static content and only a form data that was more of dynamic in nature which when someone contacts will push the contact form data to database.

This is the current architecture:

This has two problems:

Even though the contents are all static except form data , this need to go on a server as we need to handle the form data. My web portfolio:

The server is always up and running, we end up paying the cost for the server even if it is serving only static content or limited form data.

Solution:

If there is only form data that needs to be handled, the above solution can be changed as below and still have same functionality but without server. Proposed architecture :

The solution is achieved through following steps:

Host the static content from S3.
Create an API gateway
Create Lambda that would get the form data from API gateway ( json data)
Use the json data and send an email or
Push the json data to Dynamo DB.
Implementation:

In this implementation I would dwell on points 1 to 4 since implementing 5 is fairly similar as that of sending SES.

Hosting static website on S3. This is straight forward, the documentation from AWS is very clear on how you can host.

https://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteHosting.html

Only call out here is I had to adjust my contact page HTML to embed with the following java-script to handle the form data and send it to the API gateway. SendtoAPI is the function that actually triggers when send button is clicked on web page.


<script>
    function sendToAPI(e) {
    e.preventDefault();
    var URL = "<API Gateway URL here > ";

    var email = document.getElementById("email").value;
    var subject = document.getElementById("subject").value;
    var body = document.getElementById("body").value;
    if (email=="" || subject =="" ||body=="" )
    {
    alert("Please Fill All Required Field");
    return false;
    }

    var data = {
    email : email,
    subject : subject,
    body : body,

    };


    var xmlhttp = new XMLHttpRequest();
    xmlhttp.open("<API Gateway URL here >");
    xmlhttp.setRequestHeader("Content-Type", "application/json");
    xmlhttp.send(JSON.stringify(data));
    xmlhttp.onreadystatechange = function() {
    if (xmlhttp.readyState === 4) {
    var response = JSON.parse(xmlhttp.responseText);
    if (xmlhttp.status === 200 ) {
    console.log('successful');
    document.getElementById("contact-form").innerHTML = "<h1>Thank you for your message <br> I will get back to you soon!</h1>";
    } else {
    console.log('failed');
    }
    }
    }

    document.getElementById('contact-form').reset();

Contact page html :

<div class="col-md-7">
    <div class="form-group">
    <input name="email" type="email" class="form-control" id="email" placeholder="Email">
    </div>
    <div class="form-group">
    <input name="subject" type="text" class="form-control" id="subject" placeholder="Subject">
    </div>
    <div class="form-group">
    <textarea name="textmessage" class="form-control" rows="5" " id="body" placeholder="Enter your message"></textarea>
    </div>
    <button type="submit" onClick="sendToAPI(event)" class="btn btn-default btn-lg">Send</button>
    </div>

Creating Lambda function:

This Lambda will run on nodejs runtime. Be sure to verify your email on SES, otherwise this will throw error for email verification.

var AWS = require('aws-sdk');
var ses = new AWS.SES();

var RECEIVER = 'email@address';
var SENDER = 'email@address';


var response = {
 "isBase64Encoded": false,
 "headers": { 'Content-Type': 'application/json', 'Access-Control-Allow-Origin': '*'},
 "statusCode": 200,
 "body": "{\"result\": \"Success.\"}"
 };


exports.handler = function (event, context) {
    console.log('Received event:', event);
    sendEmail(event, function (err, data) {
        context.done(err, null);
    });
};

function sendEmail (event, done) {
    var params = {
        Destination: {
            ToAddresses: [
                RECEIVER
            ]
        },
        Message: {
            Body: {
                Text: {
                    Data: 'email ' + event.email + '\n subject ' + event.subject+ '\n body ' + event.body ,
                    Charset: 'UTF-8'
                }
            },
            Subject: {
                Data: 'Someone contacted you on your contact form ' + event.name,
                Charset: 'UTF-8'
            }
        },
        Source: SENDER
    };
    ses.sendEmail(params, done);

API Gateway:

API and Lambda go hand in hand. Integrating API gateway to trigger lambda is key for any serverless implementation. Be sure to enable CORS on API gateway otherwise the data cannot be reached to API gateway and Deploy your API.

Integrating everything:

If everything is setup in a right way, when we put some content in the contact page , the contents will be passed to API gateway which will trigger Lambda and which will in turn send email all the contents to the email verified.

When we click send, it should return us another HTML page and send the same contents to our email.

Email:

Similar flow can be redirected to have the contents posted to DynamoDB at the back if there is need to store the details. But we have everything now running full managed and serverless.

GitHub link:

https://github.com/durga533/serverless

References:

https://aws.amazon.com/blogs/architecture/create-dynamic-contact-forms-for-s3-static-websites-using-aws-lambda-amazon-api-gateway-and-amazon-ses/

My Experience with AWS Elastic Beanstalk and python

Durga Prasad Katrapally — Wed, 26 Aug 2020 12:01:50 +0000

I’m not from programming but wanted to start my learning with Python ! I recently purchased a Udemy course for Python for my personal learning and that had a project to build Web based portfolio. It also showed on how to host your Web portfolio using pythonanywhere.com. ( For those of you who do not what is Pythonanywhere.com, it is place to host your python application , you can actually host one application for free !!! That’s what I did on my Web portfolio ).

It was all fine and happy !!! Check the link below for Web portfolio:

http://durga533.pythonanywhere.com/

I’m avid lover of AWS and like the range of offerings it has .. So, I wanted to have my Web portfolio hosted on AWS to enhance my learning with Python and AWS. The straight option for me was to use AWS Beanstalk. This is a managed service which provides Platform as Service and you can run your code on small to medium work loads without worrying about the underlying Infrastructure.

Launching sample applications on beanstalk was very straight forward and the results are almost instantaneous ! But there are certain twists on actual code implementation. My code was getting uploading without any issue and application was showing healthy yet my end point URL was not reachable.

I got internal 505 errors, after a lot search on Web ( thanks Google and stackoverflow ) it was due to my application code.

There are two things that I did to keep this working.

First , Elastic beanstalk expects a file called “ application” on the top level of the your directory. If it does not finds one it would throw error like what I got. This is what I did. I renamed my previous server.py to application.py

Secondly, the story does not end here, I tried after renaming but still saw the error. I had to my variable for Flask from app to application.

These two changes helped me to finally launch the my Website on AWS. Tadaaa !!!!!!! Happy me !!!!

My Learning and conclusion:

Not every code that we see can be implemented as-is, every platform has its own dependencies that we should satisfy to host. Launching a sample application for learning gives us confidence but launching something in real world throws lot of challenges and great learning !!!!!