Chapter 6. Monitoring NGINX in Microsoft Azure

Monitoring application performance is as important as monitoring your network, infrastructure, or security. Applications contain valuable data that you can use to fine-tune performance and function or prevent possible failures. Both Microsoft Azure and NGINX offer several tools and plug-ins for detailed application performance monitoring.

Azure Monitor

Monitoring and understanding your application’s performance and being able to identify and address any issues that may affect the application or its resources are necessary tasks. Azure Monitor collects data from your Azure environment for analysis and proactive planning.

Azure Monitor captures data from a variety of sources, such as the application, OS, or custom sources. The two primary data types, metrics and logs, are kept in data stores. Metrics are measured numerical values or counts that provide a snapshot of the application or system at a specific time. They are light and fast, with a near real-time capability. Logs contain records for all sorts of different data types captured from your telemetry, such as performance data and events.

Data can be collected from any number of sources in your environment. Azure breaks these sources down into application tiers, with your application at the top and continuing down through the operating system and internal Azure resources. Each of these tiers is broken down further into more detailed sources. For example, Azure Monitor can collect data from within the application to monitor the application and code itself through user telemetry, logs, and performance indicators. It can even collect data through a REST service, allowing for custom monitoring options that won’t expose streaming data via other sources.

Azure Monitor has five categories of functions that it can perform on the metrics and logs data stores: insights, visualizations, analysis, response, and integration. These functions allow you to create dashboards, alerts, views, and much more.

There is an overview page for most Azure resources in the Azure portal that shows data collected by the monitor. For example, with the metrics explorer for a virtual machine, you can view graphs that track multiple metrics over a period of time to monitor long- or short-term performance. Or you can pin individual charts to a dashboard to provide a broad view of the information you’re monitoring across your environment.

Additional Tools Available in Azure for Monitoring

Dozens of monitoring tools made by third-party vendors are compatible with Azure. Among these, AppDynamics, Datadog, and Dynatrace also offer plug-ins for both NGINX OSS and NGINX Plus.

AppDynamics
This is a full application performance–monitoring suite for monitoring enterprise applications for optimization and fine-tuning. In Azure, it has tools to monitor native services like Azure Cloud Services, virtual machines, and data storage. The AppDynamics NGINX plug-in offers additional monitoring of active connections, number of requests, accepted and handled requests, and more.
Datadog
This is a popular monitoring and analytics tool in DevOps for monitoring servers, databases, and applications throughout Azure. For NGINX OSS, Datadog monitors total requests and accepted/handled/active connections. More metrics are available for NGINX Plus, such as SSL, caches, upstream server metrics, and errors.
Dynatrace
Dynatrace provides monitoring for the full Azure environment without manual configuration. It uses AI for automated monitoring. NGINX integration is very robust, including network traffic analysis and retransmission metrics.
TICK with Grafana
This is an open source monitoring solution. TICK stands for Telegraf, InfluxDB, Chronograf, and Kapacitor. Grafana is best known for its data visualization capabilities. Telegraf is a Python-based data collector agent used mostly for its ease of configuration, while InfluxDB is a time-series database known for its speed; Chronograf is the UI and administrative component of InfluxDB. Kapacitor is an open source data processing framework.

Azure Security Center with NGINX

The move to cloud and hybrid solutions requires additional security practices. As its name implies, Azure Security Center is a native Azure service that provides threat prevention, detection, and response tools. There is a free tier with limited functionality and a fee-based standard tier with a complete set of security capabilities for organizations that need enhanced functionality. The free tier monitors compute, network, storage, and application resources in Azure. It also provides security policy, security assessment, security recommendations, and the ability to connect with other security partner solutions. The standard tier includes the capabilities of the free tier for on-premises environments (private cloud) plus other public clouds such as Amazon Web Services (AWS) and Google Cloud Platform (GCP). The standard tier also includes many more security features, along with the following critical security controls:

  • Built-in and custom alerts
  • Security event collection and advanced search
  • Just-in-time virtual machine (VM) access
  • Application-specific permissiveness

The NGINX configuration deployed to Azure VMs and VMSSs can have the Microsoft Monitoring Agent installed to read various security-related configurations and event logs from the VM for monitoring in Security Center. This provides a unified view of Azure resources, including NGINX resources.

Azure Monitor with NGINX

Meaningful metrics play a crucial role in helping to understand applications and the underlying services and infrastructure they run to create nominal operational baselines and detect, investigate, and diagnose issues.

Azure Monitor integrates the capabilities of Log Analytics and Application Insights for end-to-end monitoring of applications that include NGINX as well as the VMs and VMSSs hosting NGINX.

Syslog is an event-logging protocol common to Linux and is the best way to consolidate logs from multiple sources into a single location. The Microsoft Monitoring Agent (MMA) for Linux hosting NGINX configures the local syslog daemon to forward messages to MMA, which then sends the messages to Azure Monitor, where a record is created.

Azure Governance and Policy Management for NGINX

Azure provides a suite of tools and services to provide management to maintain applications and their supporting resources. Azure Governance is one of those tools. Azure Governance offers the following features and services that can be implemented across all your Azure environments:

  • With Azure Management Groups, you can create flexible hierarchies for applying policies across multiple subscriptions.
  • Azure policies enforce different rules and effects over your resources.
  • Azure Blueprints allow the creation of fully compliant environments and the ability to apply group policies to new Azure subscriptions.
  • Azure Resource Graph allows fast visibility into all your resources.
  • Cost Management allows the analysis of costs and the ability to monitor usage from a single dashboard.

NGINX, as well as the VMs and VMSSs hosting NGINX, can be managed with the functionality provided in Azure Governance.

Azure Sentinel

Azure Sentinel is a managed SIEM (security information and event management) and SOAR (security orchestration, automation, and response) solution. Azure Sentinel collects all of your log and metric data and analyzes it for security incidents using machine learning. This machine learning is bootstrapped by training from years of security work done at Microsoft and further learns from your data to correlate what is normal for your application.

Sentinel Integration

Azure Sentinel looks at all the data with which you can provide it to correlate and hunt for threats and incidents. The more data sources you provide to Sentinel, the more perspective it has. Azure Sentinel can monitor a vast array of different types of data. The simplest integrations are called service to service and are direct integrations:

This set of integrations puts you in a really good place to detect threats and security incidents. Azure Sentinel can correlate events from AD with Office 365 and determine how events in those services may have been related to an Azure WAF incident.

Next, Sentinel is able to connect to a number of external solutions though their APIs. These solutions have integrated with Sentinel in such a way that Sentinel understands how to retrieve logs from the service’s API. These logs are harvested and put into Azure Log Analytics where Sentinel can utilize them. Some of these external sources include:

These integrations will enable Sentinel’s use of common security systems that may live outside of your Azure cloud footprint. By connecting multiple solutions as data sources, we’re able to bring all our security monitoring under a single pane of glass, which not only aids in our discovery but also strengthens the machine learning that’s flagging events.

Other services that are not yet listed can be integrated with Sentinel through the use of an agent that acts as a syslog receiver. The logs are collected by the syslog receiver and then sent to Log Analytics, where they’re made available to Sentinel. The syslog receiver converts the log stream from the common event format (CEF) and into the format needed for Log Analytics. Services that can integrate with syslog to use the Log Analytics/Sentinel agent include the following:

NGINX Sentinel integration

To integrate NGINX with the Log Analytics/Sentinel agent, you just need to turn on syslog in the NGINX configuration for the log directives:

error_log syslog:server={ip_of_Receiver} debug;
access_log syslog:server={ip_of_Receiver},facility=local,tag=NGX,severity=info;

The prior example configures NGINX to send syslog messages for errors generated by NGINX and also turns on the debug log, which provides valuable connection information when looking for security events. The example then logs all access logs to the syslog receiver, tagging them with information compliant with the common event format.

The facility attribute is meant to identify which part of the system the log came from; examples of facility names include kern (for kernel), mail, daemon, auth, and audit. The tag attribute can be any value we’d like to use; NGINX is a good identifier, but we may want to set this to be specific to a DNS name NGINX is listening for, in which case we would define our aces_log directive within a server block and use something more specific. The severity attribute is a predefined severity type; NGINX sets this to info by default. There are a number of other options, such as debug, warning, error, and critical.

More information about the syslog protocol and the CEF format can be found in the RFC 3164.

Sentinel Monitoring

Sentinel Workbooks are the same as Azure Monitor Workbooks; however, they’re presented differently, with security in mind. You can configure your own workbooks to enable you to view your data in any way useful to your security processes. These dashboards allow you to build detailed or high-level views of specific portions of your system while also being able to pull information from any of the data sources you’ve enabled.

When Sentinel detects a threat or security event, it produces analytics about that incident. An incident is reported, and data about the incident is correlated and presented to you in a concise format. Incidents are classified into severity groups: Critical, High, Medium, Low, and Informational. An incident goes through the Open, In progress, and Resolved states. This enables your security team to work from a queue of incidents that need further investigation or remediation.

Sentinel Automation

Sentinel enables you to automatically respond to security incidents with automation through the use of playbooks. A large number of playbook integrations enable Sentinel to send messages to different systems, which may issue an alarm or take action. These integrations can also respond to the playbook so that it can further process the incident until it is resolved or sent to a human for further investigation and remediation.

A playbook is able to control the workflow as a state machine, sending notifications to managed or on-premises connectors. During the workflow, the information passed to such connectors can be manipulated with variables about the incident for basic string and object manipulation. Custom code can also be triggered to enable integration with any system or to build custom response actions by use of Azure Functions and direct inline JavaScript. You may use these abilities to integrate with third-party systems that are not prebuilt connectors or respond to incidents directly.

Sentinel provides a one-stop shop for security monitoring and response. Collecting information from all data sources possible provides Sentinel with a bird’s eye view of your technology and the events that happen within it. Through the use of machine learning, Sentinel is out-of-the-box smart on security events and will automatically start to determine patterns of normal usage to spot anomalies. The incident management enables your team to stay on top of events and make sure that they’ve been handled. And finally, the automation abilities provide you with the capability to automatically respond to incidents, by notifying the appropriate parties, taking some action, or processing the data further. Azure Sentinel is an extremely valuable addition to any security team’s tool box.

Azure Governance and Policy Management

Azure Governance is a portion of the Azure Management area that specifically focuses on policy and cost management. Azure Governance is not a single product but rather a methodology that employs a number of Azure’s features.

Governance starts by organizing your subscriptions into management groups. Management groups are logical containers of Azure subscriptions that create a hierarchy. The hierarchy enables you to apply group-wide policies that are inherited by a child from a parent. When you get started with Azure Management Groups, a root group is automatically created for you, and all subscriptions within the directory become children of the root group. Azure enforces a single hierarchy strategy to provide the administrator the ability to create top-down policies that apply to the entire directory.

Management groups

Management groups can be divided into a hierarchy that makes sense for your organization. It’s typical to see groups organized by business units, by teams, and then perhaps by project or product or environment. You can build up to 10,000 groups and have a tree that branches six levels, not including the root group.

Once you have a root group, and some hierarchy built up, you can start to apply policies to groups. Policies help to enforce standards and compliance within Azure. You can use policies to govern things like which Azure regions can be used, which SKUs can be consumed for different types of services, resource types available, and tagging.

Policies

With policies, you provide the intent of the standard you want to enforce. Policies can be applied to audit or deny actions. When you get started with policies, resources already provisioned to a subscription will be flagged in an audit capacity as non-compliant, and remediation recommendations are provided; in addition, a remediation task is created to track the remediation effort.

Policies are different from role-based access control (RBAC). Policies do not have anything to do with the user’s permissions; they’re specifically about the resources being requested and ensuring that they meet the organization’s standards.

When a resource is requested that does not conform to the policy, either the resource is flagged as noncompliant when the policy is in audit mode, or it is blocked from being created if the policy is set to deny. Other actions can be performed as well, such as auto-remediation, where the policy can alter the resource change request before or after the resource is provisioned.

Policies or sets of policies can be applied to management groups and subscriptions as well as to resource groups. It’s suggested that you start from the topmost, broadest policy and work your way down to the lowest, most restrictive level, because of the hierarchy structure.

Any of the load balancers that you create will exist within a resource group. There can be multiple resource groups within a subscription, and multiple subscriptions within a management group. As described previously, there can be multiple management groups within an Azure directory that make up a hierarchy. Given that, at any point there may be up to three or more policies applied. The highest level takes precedence, and rules are applied from the top down within the hierarchy of management groups, subscriptions, and resource groups.

With this layered approach, administrators are able to build complex, multitiered governance over the organization’s use of Azure. This control enables them to specify which regions are available for use, what type of resources can be used, and the size of those resources.

Cost management

These concepts pair with Cost Management because they enable the ability to restrict usage for certain levels of logical resource groupings within Azure. Currently in Azure Cost Management, you can scope by management group, but you can’t filter or group by management groups. Azure Billing has its own separate hierarchy that is unrelated to the management group hierarchy. This makes sense when you consider that the management side of things does not always map one-to-one with the accounting side of the organization.

One way to aggregate costs is through the use of tags, which, as you may remember, is one of the resource attributes you can govern with policies. At your root management group layer, you can enforce a policy that requires specific tags to be set for billing aggregation. Within a child management group layer, you may default the tag to a value, and so on down the hierarchy. Tag policies and defaults can be set at any layer; it simply makes sense that sublevels are where things would be defaulted.

Example scenario

As an example, let’s examine an Azure VM running NGINX as our resource request. The NGINX VM must exist within a resource group, within a subscription. The subscription is logically grouped under a management group named Sandbox. The sandbox management group is a child of the App-Dev management group, which is a child of the root management group. Figure 6-1 shows this hierarchy in a diagram.

Figure 6-1. Example of governance hierarchy.

At the root layer, we may apply a policy that all resources must be tagged with the following tags:

  • Business Unit
  • Environment
  • Application
  • Service

In our child management group, Sandbox, we can enforce all of these tags as well but default or require the Business Unit tag to be set to “App-Dev.” In the child management group of the App-Dev management group, we can default or require the Environment tag to be set to a value of “Sandbox.” The subscription may have a policy, though it also may not enforce any tagging standards or defaults. Applying a policy to the resource group may default or require the Application tag to be set to the name of the application or service offering. At this point, the only tag that is not set by default is the Service tag. This means that when we create our NGINX VM, we must specify that a tag named Service is set to a value.

When we create the NGINX VM, specifying that the Service tag be set to a value of “NGINX,” our VM will be created and automatically tagged as follows:

  • Business Unit: App-Dev
  • Environment: Sandbox
  • Application: Ecommerce 
  • Service: NGINX

With this layer of governance, we’re able to ensure that accounting is able to aggregate costs down to the service level of an application within any environment for any business unit.

Furthermore, we’re able to control what size of VM is used for NGINX by specifying policies that restrict SKUs. For example, let’s say that marketing requires various types of large instances for machine learning, and we do not wish to cap the SKU usage for VMs at the root level. We can specify that the App-Dev business unit’s Sandbox management group must run only Standard-level VMs but that the production environment must be able to use certain specialized SKU types.

We would apply a policy to the Sandbox management unit that specifies that only Standard SKU VMs are allowed to be created. This enables us to manage spend by not allowing our development team to utilize overly provisioned machines for testing.

With geological/regional controls, we’re able to define where the virtual machine is created. The other feature of policies allows us to specify which services are available for use—for example, enabling directory services in the IT management group but not in other groups.

With these controls, you’re able, through a hierarchy, to govern what gets created where in your Azure environment without having to consider who is requesting the resource, enabling a high-to-low-level control interface over your environment.

Conclusion

This chapter covered general information about Azure governance, monitoring, and security. This information provides you with multiple options for controlling your Azure subscription hierarchy, in which your load balancers live, and for monitoring your load-balancing solutions at multiple layers, including security.

In the final chapter, we will take a closer look at security in the context of NGINX and Azure Firewall.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.21.158.148