The past few years have witnessed a massive increase in the adoption of cloud-native technologies to keep up with the growing demand for digital innovation, with the COVID-19 pandemic exacerbating that trend. Cloud-native promises organizations easily scalable and resilient infrastructure, agility, and faster time to market - and has always delivered on these promises.
The cloud-native application architecture - the containers-based environment, microservices architecture, service meshes, immutable infrastructure, and declarative APIs - have added layers of complexity to already complex architecture. Yet, cloud-native has made all application structure, configurations, and run-time behavior declarative, giving developers, Ops, and security teams standard ways to manage such a complex stack. But there’s one major caveat - security.
The major deconstruction of monolithic applications into microservices, although simplified individual applications’ management, has significantly increased the threat landscape. About 67% of breaches are due to misconfiguration, according to an IDC 2020 survey. These misconfigurations include both infrastructure, container orchestration, and application layers.
And now the question here becomes, how can organizations reap the benefits of cloud-native technologies, in a secure and sustainable manner?
Introducing Cloud-Native Application Policy Pack
At Magalix, we’ve decided to help teams and organizations tighten the security of their applications and containers through the Cloud-Native Application Policy Pack.
Built in-house, and based on our numerous conversations with customers and our ongoing analysis of the security landscape, this pack can get you started in tightening your security gaps, in two weeks or less. This policy pack focuses on the best security and configuration practices to avoid exposing critical databases, endpoints, or any other assets/resources.
We have structured our pack as follows:
- Application Name - [ Kubernetes, Prometheus, MongoDb, Mongo-express, MySQL, postgres, mariadb, rabbitmq,InfluxDB].
- Entity - [Workloads, namespaces, networking, nodes, storage, access control ].
- Policy Name
At the heart of Cloud-Native is Kubernetes. By default, Kubernetes ships without many security features enabled. Based on best practices established by the Cloud-Native community, combined with experiences from our internal teams and the variety of unique use cases we’ve encountered, we have established an extensive library of Policies that will provide insight into your Kubernetes cluster’s configuration and security posture. These Policies are designed to identify, block and prevent misconfigurations from creating vulnerabilities within your cluster.
As one of the defacto ways to monitor your Cloud-Native infrastructure, Prometheus provides great insights into your clusters, applications, and microservices. In order to leverage Prometheus to its fullest potential, it requires certain Kubernetes RBAC permissions, and workload annotations to identify which services to scrape. Granting additional elevated permissions such as “patch”, are not required to run Prometheus successfully and should not be allowed. In addition, enforcing a standard, such as requiring all workloads to have a scrape annotation, should be enforced as part of an overall governance strategy. Our Prometheus Policies include checking for elevated RBAC permissions and the declaration of a scrape annotations in workloads.
MongoDB is a popular document database built for the Cloud. The container image pulled from the official Docker Hub image uses environment variables to assist with certain configurations. When using the official Docker image, our Policy library includes MongoDB Policies that enforce the setting of a Mongo root username, password, and initial DB. Not setting up a root user and password will not enable authentication, leaving your Mongo instance accessible without specifying any credentials.
Mongo-express is a web-based MongoDB admin interface written in Node.js, Express.js, and Bootstrap3. Having administrative control of your Mongo instances is a must, but because of its utility Mongo-express has configurations to set the credentials for the Admin interface, SSL, and credentials to access each MongoDB database. When using the official Mongo-express image from Docker Hub, these configurations can be set using environment variables. Allowing “false”, or simply not setting any values will leave your administrative interface open for anyone to access. Our Mongo-express Policies are set to check for these vital configurations.
MySQL is a popular relational database management system. Like other databases, setting credentials is imperative to keeping non-authorized users from easily accessing your data. When using the official Docker Hub image, username and password configurations are set using environment variables. In addition to some database configurations, our MySQL Policies check for authentication environment variables, and prevent the usage of environment variables that bypass any authentication.
PostgreSQL, or Postgres, is a popular object-relational database management system. Like other systems that store data, Postgres authentication should be set to prevent unauthorized access. When using the official Docker Hub image, these configurations, amongst others, can be set using environment variables. Our Postgres Policies are set to enforce the setting of these authentication environment variables along with the other variables exposed in the official Docker image.
MariaDB is a database made by the original developers of MySQL. When using the official Docker Hub image, environment variables can be set to configure your MariaDB instance. Due to its compatibility with MySQL, environment variables prefixed with MARIADB_ or MYSQL_ can be used. Our MariaDB Policies cover both. Like other data stores, setting up user credentials is the first step in securing your data from unauthorized access. In addition to some database configurations, our MariaDB Policies check for authentication environment variables, and prevent the usage of environment variables that bypass any authentication.
RabbitMQ is open source message broker software (sometimes called message-oriented middleware) that implements the Advanced Message Queuing Protocol (AMQP). When using the official Docker Hub image, environment variables can be set to configure your RabbitMQ instance. These environment variables range from networking configurations, directory locations, and SSL requirements. Our RabbitMQ Policies are set to check if these environment variables are set so that instances of RabbitMQ are configured with security and governance in mind.
InfluxDB is a time series database used as a backing store for any use case involving large amounts of time stamped data, including DevOps monitoring, application metrics, IoT sensor data, and real-time analytics. As with other databases, authentication is the first step in protecting your data from unauthorized access. When using the official Docker Hub image, these authentication settings along with other configurations can be set using environment variables. Our InfluxDB Policies are set to check if these environment variables are set so you can be assured that instances of InfluxDB are configured with security and governance in mind.
The Policy Pack is continuously growing; in fact, we are cooking some new policies right now. Check back every week to see our latest policy additions.