When security is no longer an option: Let’s talk about the invisible battlefield in microservices

Imagine you spent several months building a servo motor control system. The servos of each joint are adjusted with extreme precision, and the movements of the robotic arms are as smooth as dancing. But one morning, you find that a module suddenly "failed" - not a mechanical failure, but someone slipped in through a small door that you didn't even notice and quietly changed a few parameters. The whole system is still working, but you know, something is different.

This is probably the feeling that many people face every day in the microservice world.

Why are we always patching holes?

Someone once asked me a question: Why do many teams always "remediate" security issues? In fact, the answer is quite simple - because at the beginning, you don't know where the door is.

Microservice architecture is like a complex mechanical transmission system. Each service is an independent gear, they rotate independently and mesh with each other. The trouble is, the more gears there are, the more gaps there are. You stare at the main drive shaft and forget that that little lubrication pump can get stuck too. By the time you hear any abnormal noise, wear and tear has already occurred.

The traditional approach is to cover the entire system with a protective shell. But microservices don't like covers - they need to breathe and scale flexibly. So security becomes the art of putting tape on every connection point. Make up for here today, make up for there tomorrow, always catching up.

Another perspective: security should be built into the system

A few years ago, I suddenly figured out something while debugging a six-axis robotic arm. The best security mechanism is not an external lock, but the "mechanical properties" built into the design. Just like the feedback circuits inside the servos, they are not installed afterwards, but are part of the motor rotation.

The security of microservices should also be like this. It shouldn't be an item on a checklist, but an inherent attribute of every service.

But how?

Debunking three common myths

Myth 1: “That’s enough if we have a firewall” This is like installing a lock on the door of your machine shop but leaving the windows open. Communication between microservices often occurs on the internal network and is not visible to the firewall. Those service-to-service calls are like transferring parts between various workstations in a workshop - even if the door is locked, parts are still circulating internally.

Myth 2: “We use the latest encryption technology” Encryption is important, but it’s like applying the best anti-rust oil to precision gears. If the person applying the oil forgot a small bearing, or applied it too thickly and affected heat dissipation, the problem still exists. Encryption misconfigurations, key management confusion, expired certificates...these are the details that go wrong more often than themselves.

Myth 3: “Our code is all reviewed” Manual review is great, but it’s like visually inspecting every gear for tooth marks. When you have hundreds of services, updated every week, something is always missing. Not to mention those third-party libraries you rely on - just like the finished gear you buy, you believe in its quality, but do you really understand every heat treatment process?

a smarter strategy

I later developed a habit: every time I design a new module, I ask myself two questions:

1. If this service wants to do bad things, how far can it go?
2. If someone wants to do something bad to this service, where is the easiest place to start?

This may sound a little neurotic, but it works. Just like when designing a mechanical structure, you not only consider how it moves, but also what to do if it gets stuck.

Specifically, I will focus on these places:

• Identity is not just a key. Giving each service a clear identity is like giving a number to every tool in the workshop. But more importantly, the identity should have clear scope of authority—this wrench can only tighten nuts of a certain size, this welder can only be used at a certain work station. Permissions should be detailed and just enough.

• Conversations need supervision Every call between services should be logged and inspectable. Not monitoring, but like a work flow card in the workshop - who took what part, handed it to whom, and when it was completed. In this way, when there is a problem in a certain link, you can quickly find clues.

• The default setting is "Deny". The default setting on many systems is "Allow" until you explicitly disable it. It’s like a workshop where all the tools are available by default. A better approach is to do the opposite: all operations are denied by default, and only those that are clearly needed are allowed. Although the initial configuration is more troublesome, it is much safer in the long run.

• Don’t trust the internal network. Doesn’t the workshop need internal management? Quite the opposite. It should be assumed that the inside is just as dangerous as the outside - a compromised service can become a springboard for attacks on other services. Communication between services also requires authentication and encryption, even if they are in the same computer room.

existkpowerin practice

Once we needed to upgrade a customer's automated production line control system. The original system had a monolithic architecture and security measures were concentrated at the edge. When migrating to microservices, we did not rush to write new code, but first drew a "trust map".

Each service is a node, and the connections between nodes represent communication relationships. Then we did something fun: we colored each line. Green indicates high trust, yellow indicates limited trust, and red indicates the need for strict review.

The resulting image looked like an abstract painting—mostly yellow, very little green, and red scattered here and there. The customer was a little nervous after seeing it: "With so many restrictions, will the system not run?"

I said no. It's like installing limiters and torque sensors on each joint of a robotic arm - they don't interfere with normal movement and only work when there is an abnormality. Three months later, the system went online, and the operation and maintenance team reported that although the configuration was a bit complicated, they could sleep much more soundly at night.

Back to the original question

What should safety be? In mechanical design, it is the safety factor of materials, redundant support structures, and failure mode analysis. In microservices, it is the identity awareness of each piece of code, the clear boundaries between services, and the default cautious attitude.

It is not an add-on, but part of the design philosophy. Just like you don't think about dustproofing after the precision guide rail is installed, you know it runs in a clean environment from the beginning.

Now when you look at your own microservice architecture, you may want to change your perspective: the calls between services are not just data transmission, but also the transfer of trust. And every transfer should have appropriate supervision and protection.

After all, good systems don’t develop resilience only after vulnerabilities arise. It should prevent attacks from starting before vulnerabilities appear. The difference between this is often the difference between daily stable operation and late-night emergency repairs.

Established in 2005,kpowerhas been dedicated to a professional compact motion unit manufacturer, headquartered in Dongguan, Guangdong Province, China. Leveraging innovations in modular drive technology,kpowerintegrates high-performance motors, precision reducers, and multi-protocol control systems to provide efficient and customized smart drive system solutions. Kpower has delivered professional drive system solutions to over 500 enterprise clients globally with products covering various fields such as Smart Home Systems, Automatic Electronics, Robotics, Precision Agriculture, Drones, and Industrial Automation.