How to Enable Logging: Secure Cloud-native Development Series

Build secure cloud-native applications by avoiding the top five security pitfalls we lay out in our Secure Cloud-native Development Series. This blog is the second part of the series, and it will teach you how and why to enable logging from the start. 

We’re going to talk about enabling logging (cloud logging, to be specific). What’s the difference? Not much, other than the fact that it’s another managed service integrated with the tools we should already be utilizing.  

Why Enable Logging? 

All developers/engineers know we need logging. But other conflicting priorities and time constraints get in the way sometimes, and it becomes a “we’ll do that on the next sprint”. I have worked on the engineering side of things as well as the security side, where I needed to track down network/application issues, or security incidents, only to find that we didn’t have logs or logging enabled on specific services.   

Enabling logging can be compared to our own health. Even when we are young, we still need to go to our physician for routine checkups, especially as we get older. If we ignore going to the doctor, we may find ourselves dealing with a medical emergency that could have been prevented by these routine checkups.  

Not having logging enabled initially may not cause any concern. But as time goes on, there may be issues or system degradations that could have been prevented by having it enabled and monitored. Cloud vendors have great logging tools we can utilize, but they need to be built in from the start.  

What’s the point? If it will affect production or is running in production, enable logging from the start for all application, network, and system level services! To learn more information on why to enable logging, you can consult the OWASP page on logging here. 

Each cloud vendor has great logging services that are integrated closely with each of their cloud services. We’ll now briefly go through a few, and I'll cover how to use and configure them.

3 Tools That Can Help Enable Logging (& How to Use Them)

Here's how to use three tools to enable logging. The first two are from Amazon Web Services (AWS), and the third is from Azure.

Logging Tool 1: CloudTrail

CloudTrail is an audit logging service that monitors and logs API calls made to the AWS account and its services. Whether run through the UI, CLI, or an SDK, the calls that are made are logged to this service.  

For example, if a set of access keys get compromised, all API calls get logged of what occurred while using those keys. In the example below, the CLI ‘get-caller-identity’ command on the right, can be queried for from CloudTrail using the CLI on the left. 

CloudTrail is already turned on by default. However, additional configuration is required. Some of those additional configuration changes can include: 

• Create a ‘trail’ for your organization’s accounts, as the normal configuration that is enabled only gives accounts a 90-day retention. However, dropping it into an s3 bucket ensures we have the retention period our organization requires. Multiple trails can also be configured for each team that requires these logs. This is very handy! And 90 days is not enough (speaking from experience)!

• Forward the trail to a dedicated security account s3 bucket. This additionally makes managing access controls not only centralized but also more secure, as fewer individuals have been granted access to this account.   

• Secure the logs. AWS offers options such as object locking so they can’t be removed. Another option is MFA delete, where the log files can’t be removed or modified without having access to your MFA device. 

Why it’s important: When using managed services such as S3, ECR, EKS, EC2, etc, CloudTrail can give the engineering, security, and SRE teams the integrated visibility they need to investigate incidents, debug system performance, as well as many other things. CloudTrail is the main source that feeds into other AWS services such as Guard Duty, and Security Hub.  

Logging Tool 2: CloudWatch

CloudWatch monitors resources and applications that can be queried on for different metrics. It’s like Nagios for the managed cloud services. For example, regarding Amazon’s Kubernetes Service (EKS), some of some of the metrics that CloudWatch can monitor are: 

• the percentage of memory currently being used by each pod, node, cluster, or instance;

• CPU metrics for each pod, node, cluster, or instance;

• network bandwidth used by each pod, node, cluster, or instance;

• and metrics around the number of pods.

Though there are many tools out there that can accomplish this in the same way, CloudWatch is integrated into the cloud environment and tools. If we are going cloud native, integrated tools are a win-win since we can use other AWS services like Simple Notification Service (SNS) to alert when thresholds are crossed.    

Why it’s important: As a developer, this information may not be of use as much to us as it will be to architects or SRE teams. However, having visibility into your managed services, such as EKS or ECR, is critical in helping us plan for future deployments and most likely will also affect future architectural design changes. These tools allow organizations to create dashboards for every specific use case. 

Logging Tool 3: Monitor

Monitor is the auditing and logging platform for all of Azure. The same features we get with AWS, we get here as well. We get the same platform logging activity as CloudTrail, and also it's enabled by default from the beginning. There are many different logging services under this umbrella for our specific use case.

So, what do we need? Obviously, this is an area of cloud costs that can get out of control very quickly if we are not careful. If it will affect production or is running in production, enable logging and alerting from the start for all application, network, and system level services. Application Insights, Container Insights, and/or VM Insights may fit our use case.   

Application Insights speaks to developers, though! It can be enabled by either running an installed agent or embedding the SDK to our application.  It offers great visibility into our application performance metrics, live usage data, as well as transactional tracing information. Though again, there are many tools both commercial and open source that can give us this, but when going cloud native, having these integrated tools simplifies a lot of management and configuration for us.       

Why it's important: These integrated monitoring and auditing services are essential to cloud-native development.  Additionally, Azure integrates well with a hybrid architecture, allowing visibility from the on prem resources alongside our Azure cloud resources.

Takeaways

Logging and auditing are a key component of our applications. Cloud providers offer powerful logging services that can be utilized for dashboards, alerts, and monitoring for issues. As stated previously, there are many tools that accomplish the same things and have different costs. However, the benefits show themselves with the easy management and configuration to deploy more quickly.  

It makes it easier to deploy and scale when combined with a resource templating tool like CloudFormation or Azure Resource Manager, where our logging configurations can be cloned and repeated across environments without having to manually configure each instance.  Simplify it where we can, and ensure you have the visibility you need when you need it! 

Next time, in Part 3, we’ll talk about Storage. See you then! 

In case you missed it, learn how to choose secure container images in Part 1.