If you’re in the process of evaluating solutions for monitoring your cloud-native apps, this guide to selecting the right Prometheus-native monitoring solution is here to help.
Over the course of four posts, we explore why a Prometheus-native monitoring solution is best, what qualifies as Prometheus-native, and we define the four key capabilities your monitoring-solutions vendor should offer, including:
- Availability and Resiliency
- Cost & Control
- Security & Administration (current blog)
- Performance & Scale
So far we’ve discussed availability & reliability as well as cost & control. We also defined the meaning of Prometheus-native. In this third installment, we explore why security & administration is also a must-have in your next Prometheus-native monitoring solution.
Security and administration
Security should be designed into your monitoring platform technical infrastructure in order to provide security through all information and data processing. This means providing secure storage of data and end user privacy safeguards, secure transmission between services, secure and private communication with customers, and safe operation by administrators.
For starters, you’ll need to understand what fine-grained security and access controls the vendor has put in place to protect your metrics data. You’ll want to ensure that all user or machine communication is encrypted and that both user and service accounts leverage secure authentication systems. Also look for:
SOC 2 Type II compliance
SOC 2 Type II compliance should be a top consideration of any SaaS monitoring solution. As part of the AICPA’s (American Institute of CPAs’ Service Organization Control) reporting platform, SOC 2 compliance helps ensure the safety and privacy of customer data transmitted and stored in the cloud. Verifying your vendor meets SOC 2 compliance criteria means knowing that a third-party has verified the vendor’s security policies, procedures, and practices. What’s more is that they maintain these best practices consistently (the “type II” component of the compliance shows that they have not only set up these procedures, but also continued to follow them for a period of time).
Administration and access control
Administration and access control is also a vital piece of the security puzzle. It’s critical for administrators to get access to make changes to metadata like dashboards and alerts, etc. However, if users have these same permissions, the results could be catastrophic. The administrators must be able to restrict users to reading various subsets of the underlying data (metric data itself). For example, developers must be able to see other teams’ environments, but should not be able to make potentially breaking changes. The easiest way to manage access and user control is for your monitoring solution to connect to your existing SSO/SAML to authenticate users and assign them to specific roles. Users with privileges in an organization can set the default user roles and permissions, and, if desired, they can grant users and service accounts different roles and permissions for given tenants within the organization.
When your SaaS solution uses a single tenant infrastructure, it provides a great reliability and availability advantage to customers. It also provides a significant security advantage: All of your data is completely isolated from other customers using the SaaS service. Each customer has a dedicated set of software and supporting infrastructure that only serves them. This makes the possibility of cross-account contamination, or accidental cross-account access, extremely low. It also means that if one account is breached, it won’t impact other accounts using the same service.
You’ll want to ensure your vendor is staying up to date with patches and releases from their infrastructure, operating systems, and/or cloud providers.
Secure communication means all user or machine communication to the infrastructure should enter your vendor’s Virtual Private Cloud (VPC) network encrypted over TLS. Any remote procedure call (RPC) to, or between, VPC networks should be encrypted.
Next time, in our fourth and final installment of this series, we will explore considerations around performance & scale. Stay tuned.
Other blogs in this series: