• Introduction
• Principles
• Conclusion

Introduction

In the first part, we have summed up all the essential elements to consider when working with Cloud and securing cloud-native applications/platforms. In this post, we would like to give you some concrete principles and tips for creating more secure applications.

Principles

Multi-Layered Defense

Keywords: general

First of all, a more generic but important principle: It would be best to look at security as a whole – integrating various security layers on multiple levels in any system. It should include cyber-security plans for:

1. Devices
2. Applications
3. Networks
4. Infrastructure
5. People

Think of this principle as all the layers of clothing you wear to protect yourself from cold and bad weather. If one of the layers is compromised, there is always another to keep you warm and dry.

Identity and Access Management (IAM) Misconfiguration

Keywords: network, permissions

You need to control access and permissions meticulously and over time. Things to consider:

• Implementing role-based access control (RBAC)
• Principle of least privilege
• Routines for updating and removing permissions when they are no longer needed.
• Explore possibilities for using time-based conditions for IAM policies.

API Security

Keywords: endpoints, permissions

• APIs act as the gateways to your application and data. Securing access to and securing them from known vulnerabilities is paramount to prevent unauthorized access and data breaches.
• Utilize authentication, authorization, and API gateways to control access and protect sensitive information. Don’t forget to monitor the software or libraries that make APIs available (e.g., runtimes, middleware)

Data Encryption

Keywords: data

• Safeguarding data at rest, in transit, and during processing is critical for your applications.
• Utilize encryption, tokenization, and data masking techniques to ensure data protection. Removing unnecessary sensitive information can simplify some of these tasks.
• If a platform or a Cloud provider provides the encryption, consider if you would like to use the standard keys for encryption or “bring your own” and manage them yourself or through a third party.
• Beware: Don’t write your own crypto! Ever.

Zero Trust

Keywords: network, permissions

• The Zero Trust security model assumes that no one is inherently trustworthy, even those within your network.
• This is opposed to more traditional approaches where perimeter security was prioritized over security inside the network.
• Adopting this approach, every request, user, and device is thoroughly verified before gaining access.
• Again: Implement the principle of least privilege, where users are only granted the minimum level of access required to perform their tasks.

Software Supply Chain Security

Keywords: software, environment

• Create Software Bill of Materials (SBOM) for your software
• Governance: Know where all the building blocks (artifacts) of your software are coming from.
• Automate security checks within your CI/CD pipeline to catch vulnerabilities early and often.
• Use static code analysis with tools like SonarQube to scan your code for potential security flaws and integrate those checks into your CI/CD pipeline to ensure continuous security monitoring.
• Use tools to monitor not only the code you develop yourself but also all the third-party libraries you utilize in your code.
• With DevSecOps, automated security security is becoming integral to the development process. Adopt it if you haven’t done so already.

Secure Containerization

Keywords: software, environment

• Containerization and orchestration technologies, like Docker and Kubernetes, offer exceptional flexibility but also introduce security concerns.
• Securing containers and managing their lifecycle is vital to ensure a safe cloud environment.
• For example, use container scanning tools to identify vulnerabilities within container images before deploying them.
• Additionally, enforce strict security policies and segregate workloads using Kubernetes namespaces.

Continuous Monitoring and Incident Response

Keywords: software, environment

• The cloud landscape is constantly changing, and threats evolve rapidly. This means that we need to monitor not only for known threats but also for anomalies.
• Continuous monitoring and proactive incident response are essential to detect anomalies and respond swiftly to security incidents.
• For example, use cloud-native monitoring tools your Cloud or platform provider provides.
• Have good logging, but remember that more is not always better – log relevant information.

Human Factors (including Social Engineering, Misconfigurations, and Human Errors)

Keywords: people, human factors

• 82% of incidents are caused by human factors (2022 Data Breach Investigations Report)
• Creating secure applications also implies providing security training for the system users.
• Social engineering and human factor has proven to be essential to creating secure applications.
• Consider running security awareness campaigns and employee training from user and developer perspectives.
• Automate routine and mundane tasks – humans often don’t enjoy carrying out tasks like this and are prone to errors; computers, on the other hand, excel at tasks like this!

Conclusion

You have probably heard that nothing is stronger than its weakest link. Therefore, it is important to look at various sides of the security. Especially in the Cloud, one size does not fit all when it comes to security. Cloud platforms, software, and threats constantly evolve and add to the complexity of creating secure applications.

Here, we have seen some of the principles to consider regarding the security of the platforms and application development for the Cloud and cloud-native applications in general.

Finally, note that this is not an exhaustive list but is instead meant to serve as a stepping stone to more secure application development.

• Introduction
• Key Elements of a Cloud Security Architecture
• Responsibilities
• Constantly Evolving Landscape
• Platform Security Architecture
• Application Security Architecture
• Conclusion

Introduction

Whether you are running on the Cloud or not it is all about the CIA triad model – Confidentiality, Integrity, and Availability.

When thinking about Cloud Security Architecture we need to be able to think about the whole stack. Of course, we don’t need to think about all the moving parts alone – it is a shared responsibility between the Cloud service provider and you, the user of the platform.

Key Elements of a Cloud Security Architecture

Let’s first start by defining the key elements of a Cloud Security Architecture, divided across the layers of the stack, based on the Cloud Security Alliance (CSA) stack model.

Now, we can also mention some of the main challenges related to security, divided into separate groups, and try to map them to the CIA triad model that we have mentioned earlier.

Network and Storage

• Data Encryption
• Network Security

Application layer

• Application Security
• Logging and Monitoring
• Identity and Access Management (IAM)

Observability, and traceability

• Incident Response and Recovery
• Vendor and Third-Party Risk Management

DevOps

• Automation and Orchestration
• Resilience and High Availability

General

• Compliance and Governance
• User Training and Awareness
• Cloud Provider Security Features

Responsibilities

Shared Responsibility + Intersection of Responsibilities

Addressing all these challenges is a shared responsibility between the Cloud service provider and the customer and the division will vary depending on the type of the solution and whether you are using IaaS, PaaS, or SaaS.

Typically, Cloud service providers will take care of the lower parts of the stack, like physical, infrastructure, and platform security, while customers will be responsible for creating secure applications, securing their data, creating proper Identity and Access Management (IAM), and configuration management.

An effective overlap and a clear understanding of the responsibilities ensure comprehensive security coverage across all layers.

Constantly Evolving Landscape

Evolving Landscape == Constant Change

One of the differentiating factors from regular application development is the constant change and evolution of the platform and tooling on one side, and the constantly evolving types of attacks and possibly larger attack surfaces on the other side.

These factors will lead to changes in the model and the responsibility division. The same might be influenced by the new services being introduced both from the side of the Cloud service provider and the customer (app developer).

Therefore, regular communication between the parties involved and staying updated on their security practices is essential to ensure secure Cloud applications.

Types of the Cloud Security Architecture

The Cloud Security Architecture is twofold – you will need to choose a platform for running your application and think about the security of the application you will be deploying on that platform.

Platform Security Architecture

Let’s start with defining the types of platforms and list some of the key elements to consider when choosing a platform type.

Public Cloud Security Architecture

• Designed for cloud services provided by third-party vendors (e.g., AWS, Azure, Google Cloud).
• Focuses on securing data and applications hosted on shared infrastructure.
• Utilizes the security features provided by the cloud service provider (CSP) while also implementing * additional security measures.
• Emphasizes network segmentation, encryption, IAM, and monitoring.

Private Cloud Security Architecture

• Created for cloud environments dedicated to a single organization.
• Offers more control over security settings and configurations.
• Often used by organizations with strict compliance requirements or sensitive data.
• Implements strong access controls, encryption, and strict network isolation.

Hybrid Cloud Security Architecture

• Combines public and private clouds to take advantage of the benefits of both deployment models
• Security architecture addresses integration challenges and ensures consistency across environments
• Emphasizes secure communication between on-premises and cloud components
• Requires seamless identity and access management across both environments

Multi-Cloud Security Architecture

• Involves using services from multiple cloud providers simultaneously
• Ensures compatibility and security across diverse cloud platforms
• Requires careful management of authentication, authorization, data protection, and compliance measures
• Aims to prevent vendor lock-in and distribute risk

Application Security Architecture

Here are some things you will need to think about when developing modern applications for the Cloud and the cloud-native world.

1. Secure Your Code

• Software Supply Chain Security: Securing and monitoring your artifacts and third-party libraries.
• Making sure the code you have written is secure: OWASP Top 10, static code analysis, coding best practices.

2. Your Container (and Serverless) Security Architecture

• Specifically addresses security for containerized applications (e.g., Containers, Kubernetes) and serverless computing (e.g., AWS Lambda, Azure Functions, Cloud Functions, or Cloud Run on Google Cloud)
• Focus on securing microservices, communication between them, their orchestrators, and function-as-a-service (FaaS) platforms
• Involves isolating containers, securing images, and managing runtime security

3. Add DevSecOps Architecture Practices

• Integrate security practices into the DevOps process: DevSecOps
• Ensure security is considered at every stage of application development and deployment
• Involves automated security testing, vulnerability scanning, and security policy enforcement

4. Cross-application and Cross-container communication: Zero Trust Security Architecture

• Assume no trust by default and require strict authentication and authorization for all users and devices
• Focus on identity verification, principle of least privilege, and continuous monitoring
• Suitable for cloud environments where traditional perimeter defenses are less effective

5. Physical security: Edge Cloud Security Architecture

• Address security concerns at the edge of the network, closer to where data is generated and consumed
• In case of having local edge hardware devices consider also physical security of those devices
• Involves considerations like local processing, secure communication, and protection against threats targeting edge devices

6. Compliance-Centric Security Architecture

• Tailored to meet specific regulatory compliance requirements (e.g., GDPR, HIPAA, PCI DSS)
• Focus on implementing controls and safeguards to adhere to relevant standards

Conclusion

We have seen the key elements of the cloud security architecture and the building blocks of the whole stack. Furthermore, we have looked at the various types and elements to consider when it comes to the security of the platforms and application development. This is a stepping stone to categorize and group some of the main things you will need to consider when working with the Cloud and cloud-native applications.

** Illustrations in this post: Rustam Mehmandarov.

• Intro
• 1. Before you begin
• 2. Create a Cloud Function
• 3. Deploy the Cloud Function

Intro

Recently we decided to migrate our builds from Travis CI to Google Cloud Build to speed up the builds. The process was quite easy and flawless; however, we were still missing a few minor things. One of them was the notifications from Cloud Build to our #ops channel in Slack. This was slightly annoying because you would not know if the build was finished and the site was deployed, or if it failed for some reason.

Integrating with Cloud Build was a bit more different than what you are used to from integrations with Jenkins or Travis CI. Normally you would just create a webhook that would call an interface in the Slack API. In Cloud Build, on the other hand, everything is getting posted to the Pub/Sub queue built into the platform, and here you would just need to subscribe to the specific queue and listen for the events. To achieve the latter, you would need a small serverless function to listen for these events and to call the Slack API.

Note that here we will, technically, be using paid services on Google Cloud Platform, as both Cloud Build, Cloud Pub/Sub, and Cloud Functions are billable components. However, since all the components above provide a generous free tier, you will need to work hard to get passed the free tier with this setup.

• Cloud Build: Free first 120 builds-minutes per day for Basic machine type (n1-standard-1).
• Cloud Pub/Sub: Free first 10GB per month (pricing).
• Cloud Functions: Free first 2 million invocations per month (pricing).

1. Before you begin

1.1 Prepare your GCP project

I assume you have a Google Cloud Account, and that you have signed in to your account.

1. Select or create a Google Cloud Platform project, e.g. from the Manage resources page.
2. Make sure that billing is enabled for your Google Cloud Platform project.
3. Enable the Cloud Functions and Cloud Pub/Sub. You can also enable the APIs using this link.
4. Use Cloud Shell right from the browser, or you can Install and initialize the Cloud SDK on your own machine.
5. If you have installed the Cloud SDK, update and install gcloud components:

gcloud components update &&
gcloud components install alpha beta

1.2 Prepare your Slack App

I assume you have Slack installed and that you have created and signed-in to your account.

Create a new Slack app:

1. Choose the app’s name and your Slack team. Click Create.
2. Click Incoming Webhooks.
3. Activate incoming webhooks.
4. Click Add New Webhook to Workspace. An authorization page opens.
5. From the drop-down menu, select the channel to which you would like notifications sent.
6. Click Authorize.
7. A webhook for your Slack application has been created. Copy the webhook URL and save it for later use.

2. Create a Cloud Function

We need to create a Cloud Storage bucket to stage your Cloud Functions files. Use [STAGING_BUCKET_NAME] that is a globally-unique bucket name (such as [PROJECT-ID]_cloudbuilds):

gsutil mb gs://[STAGING_BUCKET_NAME]

You should see the following output:

Creating gs://[PROJECT-ID]_cloudbuilds/[STAGING_BUCKET_NAME]...

Next, create a directory on your local system for the application code:

mkdir ~/gcb_slack
cd ~/gcb_slack

Then, create the following two files in the gcb_slack directory.

File 1: package.json

{
  "name": "google-container-slack",
  "version": "0.0.1",
  "description": "Slack integration for Google Cloud Build, using Google Cloud Functions",
  "main": "index.js",
  "dependencies": {
    "@slack/client": "4.10.0"
  }
}

File 2: index.js

Note: Make sure to update SLACK_WEBHOOK_URL in the code below.

const IncomingWebhook = require('@slack/client').IncomingWebhook;
const SLACK_WEBHOOK_URL = "<INSERT YOUR WEBHOOK FROM STEP 1.2>"

const webhook = new IncomingWebhook(SLACK_WEBHOOK_URL);

// subscribe is the main function called by Cloud Functions.
module.exports.subscribe = (event, callback) => {
 const build = eventToBuild(event.data.data);

  // Skip if the current status is not in the status list.
  // Add additional statues to list if you'd like:
  // QUEUED, WORKING, SUCCESS, FAILURE,
  // INTERNAL_ERROR, TIMEOUT, CANCELLED
  const status = ['SUCCESS', 'FAILURE', 'INTERNAL_ERROR', 'TIMEOUT'];
  if (status.indexOf(build.status) === -1) {
    return callback();
  }

  // Send message to Slack.
  const message = createSlackMessage(build);
  webhook.send(message, callback);
};

// eventToBuild transforms pubsub event message to a build object.
const eventToBuild = (data) => {
  return JSON.parse(new Buffer(data, 'base64').toString());
}

// createSlackMessage create a message from a build object.
const createSlackMessage = (build) => {
  let message = {
   text: `Build \`${build.id}\``,
    mrkdwn: true,
    attachments: [
      {
        title: 'Build logs - Your Custom Message Goes Here',
        title_link: build.logUrl,
        fields: [{
          title: 'Status',
          value: build.status
        }]
      }
    ]
  };
  return message
}

3. Deploy the Cloud Function

To deploy the subscribe function with a Cloud Pub/Sub trigger, run the following command in the gcb_slack directory:

gcloud functions deploy subscribe --stage-bucket [STAGING_BUCKET_NAME] \
    --trigger-topic cloud-builds

where [STAGING_BUCKET_NAME] is the name of your staging Cloud Storage Bucket that you defined earlier.

You should see an output confirming the creation of the cloud function and status: READY.

After you’ve completed deployment of the Cloud Function, when a build event occurs, you will receive a Slack notification.

Also, feel free to customize your app, like adding a custom icon, as I did with mine. ☝️

• Posting via Confluence REST API
• Creating a Lambda Function in AWS
• Schedule it!

Some mundane tasks can easily be automated. In my case, I needed something that could post to our Confluence instance at a specific time every week. This is because we use blog posts in Confluence for announcing our weekly volunteer meetings and as a simple attendance management.

Posting via Confluence REST API

Confluence, a team collaboration software written in Java and quite often used in corporate environments, offers a REST API that makes it possible to perform many operations on the content. In this case, I was interested in posting new content with some text, and I was getting tired of doing that manually every week. So, I thought: “I spend a lot of time on this task. I should write a program automating it!”.

The first take on that problem was a simple Python script:

import json
import requests

url = "https://some-confluence-url.com/rest/api/content/"
headers = { "content-type": "application/json" }
payload = { "type": "blogpost",
            "title": "Fancy meeting title",
            "space": {
                "key": "mySpaceNameGoesHere"
            },
            "body": {
                "storage": {
                    "representation": "storage",
                    "value": "Meeting description goes here."
                }
            }
            #"history": {
            #    "createdDate": '2017-01-10T14:00:00.000Z'
            #},

        }

response = requests.post(url, 
                         data=json.dumps(payload), 
                         headers=headers, 
                         auth=("myUserName", "mySecretPassword"))
print json.dumps(response.json(), indent=4, sort_keys=True)

You should be able to run this script against your end-point and post your content. Just note that I used requests library here that needs to be installed separately, for instance, by using pip:

sudo pip install requests

Also, you will need to update the following values in the script:

• url – the URL to your site
• type – can be a blogpost or a page
• title – page or post title
• space – a Confluence space where the post will belong
• value – content of the page, can contain HTML tags
• auth – username and password (please note that, for security reasons, it might be a good idea to create a separate user with restricted access rights just for posting specific content)
• createdDate – you can also add the commented-out part to add a specific blog post date

The script uses basic authentication to post the content and, if successful, returns metadata about the post as a response. If it fails, the response from Confluence end-point should point you in the right direction.

Creating a Lambda Function in AWS

Now we are one step closer to automation. The script works, and we can post content with a simple push of a button. What now?

Well, now I needed something to run that script and something to trigger that action. The trigger is the time as I wanted to run our script weekly, but first I needed to deploy our script to the Cloud. Scheduling and triggers would come later.

Since we had some infrastructure on AWS already, I decided to deploy the script on the same platform. I wanted to deploy it as a simple stand-alone function in the Cloud – in AWS world it is called a Lambda function.

I started by wrapping our code into a function and making it AWS Lambda function compatible – to define a function that takes two arguments: event and context. I choose to call the function blogpost_handler:

#!/usr/bin/python
# -*- coding: utf-8 -*-

# File name: poster.py

import requests
import json
import datetime

def blogpost_handler(event, context): 

    # Script is run on Sunday, need to use date for Tuesday
    next_tue = (datetime.datetime.now()
                    +datetime.timedelta(days=2)).strftime("%Y-%m-%d")

    url = "https://some-confluence-url.com/rest/api/content/"
    headers = { "content-type": "application/json" }
    payload = { "type": "blogpost",
                "title": "Meeting: "+next_tue,
                "space": {
                    "key": "mySpaceNameGoesHere"
                },
                "body": {
                    "storage": {
                        "representation": "storage",
                        "value": "Meeting description goes here."
                    }
                }
            }

    
    response = requests.post(url, 
                             data=json.dumps(payload), 
                             headers=headers, 
                             auth=("myUserName", "mySecretPassword"))
    
    print json.dumps(response.json(), indent=4, sort_keys=True)

    return response.json()

Now, I needed to package the code to make it ready to deploy:

# 1. create folder
mkdir blogposter
cd blogposter

# 2. create and copy the code above into poster.py
touch poster.py

# 3. install requests package locally
pip install requests -t .

# 4. zip contents of the folder and create a zip file in a parent directory
zip -r9 ../pyposter.zip *

And we are ready to deploy to AWS! Start with creating a new Lambda Function and selecting a blank function for this job.

I didn’t choose any triggers for now and continued to the configuration page. When presented with function configuration you need to give it a name, description, runtime, and a .zip file with the code. At the end, you will need to define a handler (which will typically be filename.function_name), and a role.

At the end of the wizard, you can run it manually by pressing the Test button. If you did all the steps above, this should now create a new post on your Confluence. Congratulations, you have now set up a stand-alone function in the Cloud!

Schedule it!

Now that I have automated the task and deployed it to the Cloud, I needed something to trigger that function. In this case, I wanted to schedule it to run weekly, so function was set to be triggered by the CloudWatch events. It offers a good support for scheduling Lambda expressions.

I defined event source as a cron expression, and a target as a Lambda function I created in the previous step.

# 9:05, every Sunday
5 9 ? * 1 *

Now you (and I) have a function that is scheduled to run weekly and does not require a dedicated machine to run. It also has some good options for logging and sending alarms in case it fails.