Microservices can be deployed anywhere: in the public cloud; on-prem, or in a hybrid implementation. No matter where the microservices are hosted, they need a security strategy that scales as more microservices are built and consumed. Providing security at scale becomes difficult for anyone managing legacy computing environments transitioning to microservices.
Overall, DevOps teams are getting spread thin and forced to plan for higher levels of interactivity brought on by microservices.
The new perimeter
Cloud-native applications require IT teams to reconsider the meaning of security.
Public cloud platforms such as AWS and Azure have sophisticated tools for identity and access management (IAM). They can define role-based access control (RBAC), permitting authorised users to view or make changes to the application’s code, performing the duties of a firewall. Tools, such as AWS Inspector, identify vulnerabilities by automatically scanning cloud resources.
At the same time – any public cloud customer has a shared responsibility for security. If a customer fails to secure their resources in the cloud, then security is compromised.
Today, containerised applications change the meaning of the security perimeter…
Strategies to secure cloud-native applications include:
- Container-specific security – container images are a vulnerability source. Your team can scan container images for common vulnerabilities with image scanning features. To prevent vulnerabilities spreading to more containers, and the host, run them as unprivileged, non-root containers. Container lifespans should be short, and the container images must be small to reduce the potential surface area for an attack.
- Policy-based network security – establish a set of policies that enable automated communication between authorised services by using tools like Weave, which allows micro-firewalls to protect each service.
- Threat detection – enable holistic security with a threat detection tool that provides end-to-end monitoring.
- Centralised logs – logs assist in monitoring all events in detail. It is best to store them centrally, making them accessible via a dedicated log analysis tool.
Key microservices security issues
The current microservices DevOps environment challenges teams and developers with:
- Complicated systems – as communication between services increases, so does the number of attack vectors and the risk of failure. If the microservice fails, it presents an opportune gap for security threats to breach.
- Changing monolithic application features to microservices – transitioning an inflexible DevOps environment to microservices is difficult. The various frameworks and coding languages complicate security.
- Traditional logging is ineffective – DevOps microservices ecosystems are independent and widely distributed, so they require many logs. The more logs there are, the harder they are to identify. Microservices need to send logs across multiple hosts (within single, external, and centralised locations). Adequate microservices security requires a higher viewpoint to observe how the logs correlate across all of the platforms.
- Monitoring stress – it is challenging controlling the vast amount of new services added to the system. Automation is often a requirement.
- Application security – loading new apps onto the service requires adjustments in API monitoring. Application monitoring should be end-to-end to isolate and address issues.
- Increase in requests – when large amounts of services leverage request headers, managing these requests becomes time-consuming for the development team, and they require an autonomous security apparatus to work at scale.
- Fault tolerance – when service failures accumulate, they can result in a massive, combined failure. Microservices should focus on interdependence to ensure stability across services.
- Caching – caching may reduce the increase of requests made, but it also heightens the complexity and need for inter-service team communication.
- Security efforts – collaboration and security efforts with DevOps must be a unified, regular occurrence alongside frequent contact points at the macro and micro level.
- Future security design – to secure microservices, you should examine all possible factors that form the foundation of a stable security policy.
How Kubernetes impacts your security
Although the main aim of technology is to solve problems, new technologies, such as microservices, containers and Kubernetes introduce additional issues with management, security and compliance. The main reason for this is that they add more layers to application deployments. The design of Kubernetes cannot adequately manage all of these challenges, as each layer presents new security risks.
When you enforce a security architecture within a containerised environment, you must:
- Isolate containers and pods, as well as isolate hosts from containers and pods.
- Manage networks that compose a container cluster and isolate them from each other.
- Secure persistent data storage for the container the cluster relies on.
- Meet compliance requirements.
Containers offer new tools and strategies to overcome these challenges:
- Declarative approach – in a Kubernetes cluster, you can configure almost everything with JSON or YAML files. Your team can create files that define how the cluster should behave and how to isolate various components. Your team can then deploy them to build the environment. You can integrate security straight into the configuration of a Kubernetes environment.
- Immutable infrastructure – reduces unforeseen configuration problems; your team deploys new containers by destroying their predecessors rather than applying updates to running components.
- Larger attack surface does not mean less security – the various layers and components that containers, microservices and Kubernetes introduce increases the attack surface. The new tools assist in securing this surface.
You can design a secure, containerised, Kubernetes-based environment using declarative configuration. Make security part of the code you use to deploy and manage containerised applications, ensuring each layer has its types of security audits. Kubernetes by itself is not a security tool, so your team should be aware of the limitations and which additional tools compensate for these limitations.
LimePoint enables and secures your Microservices and Containerised Applications
Together with our technology partners, Confluent and Kong, we help enterprises transition from legacy platforms to leveraging microservices to rapidly improve their application stack. If you would like to know more about how LimePoint can assist with your microservices security needs, please get in contact with us.