Microservices Security in Action

Wajjakkara Kankanamge Anthony Nuwan Dias, Prabath Siriwardena

• Publisher: Manning
• Year: 2020
• ISBN:
  9781638350118
• Topic: Informatique
• Subtopic: Services Web et API

"A complete guide to the challenges and solutions in securing microservices architectures." —Massimo Siani, FinDynamic Key Features
Secure microservices infrastructure and code
Monitoring, access control, and microservice-to-microservice communications
Deploy securely using Kubernetes, Docker, and the Istio service mesh.
Hands-on examples and exercises using Java and Spring Boot Purchase of the print book includes a free eBook in PDF, Kindle, and ePub formats from Manning Publications. Microservices Security in Action teaches you how to address microservices-specific security challenges throughout the system. This practical guide includes plentiful hands-on exercises using industry-leading open-source tools and examples using Java and Spring Boot. About The Book
Design and implement security into your microservices from the start. Microservices Security in Action teaches you to assess and address security challenges at every level of a Microservices application, from APIs to infrastructure. You'll find effective solutions to common security problems, including throttling and monitoring, access control at the API gateway, and microservice-to-microservice communication. Detailed Java code samples, exercises, and real-world business use cases ensure you can put what you've learned into action immediately. What You Will Learn Microservice security concepts
Edge services with an API gateway
Deployments with Docker, Kubernetes, and Istio
Security testing at the code level
Communications with HTTP, gRPC, and Kafka This Book Is Written For
For experienced microservices developers with intermediate Java skills. About The Author
Prabath Siriwardena is the vice president of security architecture at WSO2. Nuwan Dias is the director of API architecture at WSO2. They have designed secure systems for many Fortune 500 companies. Table of Contents PART 1 OVERVIEW
1 Microservices security landscape
2 First steps in securing microservices PART 2 EDGE SECURITY
3 Securing north/south traffic with an API gateway
4 Accessing a secured microservice via a single-page application
5 Engaging throttling, monitoring, and access control PART 3 SERVICE-TO-SERVICE COMMUNICATIONS
6 Securing east/west traffic with certificates
7 Securing east/west traffic with JWT
8 Securing east/west traffic over gRPC
9 Securing reactive microservices PART 4 SECURE DEPLOYMENT
10 Conquering container security with Docker
11 Securing microservices on Kubernetes
12 Securing microservices with Istio service mesh PART 5 SECURE DEVELOPMENT
13 Secure coding practices and automation

Part 1. Overview

Microservices are no longer a novelty. We’re seeing large-scale microservices deployments with thousands of services. But whether we have one or two services or thousands, security is a top priority. This part of the book takes you through the fundamentals in securing microservices.

Chapter 1 teaches you why securing microservices is challenging, and takes you through the key principles in securing a microservices deployment.

Chapter 2 teaches you how to build your first microservice in Spring Boot and secure it with OAuth 2.0. You will also learn how to set up an OAuth 2.0 token issuer.

When you’re finished with these two chapters, you’ll have the right mindset to take on the challenges of securing microservices. After getting your feet wet in this part of the book, you’ll be ready to build more complex security patterns (which we teach you in the rest of the book) on top of your first microservice.

1 Microservices security landscape

This chapter covers

• Why microservices security is challenging
• Principles and key elements of a microservices security design
• Edge security and the role of an API gateway
• Patterns and practices in securing service-to-service communications

Fail fast, fail often is a mantra in Silicon Valley. Not everyone agrees, but we love it! It’s an invitation to experiment with new things, accept failures, fix problems, and try again. Not everything in ink looks pretty in practice. Fail fast, fail often is only hype unless the organizational leadership, the culture, and the technology are present and thriving.

We find microservices to be a key enabler for fail fast, fail often. Microservices architecture has gone beyond technology and architectural principles to become a culture. Netflix, Amazon, Lyft, Uber, and eBay are the front-runners in building that culture. Neither the architecture nor the technology behind microservices--but the discipline practiced in an organizational culture--lets your team build stable products, deploy them in a production environment with less hassle, and introduce frequent changes with no negative impact on the overall system.

Speed to production and evolvability are the two key outcomes of microservices architecture. International Data Corporation (IDC) has predicted that by 2022, 90% of all apps will feature microservices architectures that improve the ability to design, debug, update, and leverage third-party code.1

We assume that you’re well versed in microservices design principles, applications, and benefits. If you’re new to microservices and have never been (or are only slightly) involved in development projects, we recommend that you read a book on microservices first, such as Spring Microservices in Action by John Carnell (Manning, 2017). Microservices Patterns by Chris Richardson (Manning, 2018) and Microservices in Action by Morgan Bruce and Paulo A. Pereira (Manning, 2018) are two other good books on the subject. Microservices for the Enterprise: Designing, Developing, and Deploying by Prabath Siriwardena (a coauthor of this book) and Kasun Indrasiri (Apress, 2018) is another beginner’s book on microservices.

In this book, we focus on microservices security. When you make the decision to go ahead with microservices architecture to build all your critical business operations, security is of topmost importance. A security breach could result in many unpleasant outcomes, from losing customer confidence to bankruptcy. Emphasis on security today is higher than at any time in the past. Microservices are becoming key enablers of digital transformation, so microservices security must be consciously planned, designed, and implemented.

This book introduces you to the key fundamentals, security principles, and best practices involved in securing microservices. We’ll be using industry-leading open source tools along with Java code samples developed with Spring Boot for demonstrations. You may pick better, competitive tools later in your production environment, of course.

This book will give you a good understanding of how to implement microservices security concepts in real life, even if you’re not a Java developer. If you’re familiar with any object-oriented programming language (such as C++ or C#) and understand basic programming constructs well, you’ll still enjoy reading the book, even though its samples are in Java. Then again, security is a broader topic. It’s a discipline with multiple subdisciplines. In this book, we mostly focus on application developers and architects who worry about managing access to their microservices. Access management itself is another broader subdiscipline of the larger security discipline. We do not focus on pen testing, developing threat models, firewalls, system-level configurations to harden security, and so on.

1.1 How security works in a monolithic application

A monolithic application has few entry points. An entry point for an application is analogous to a door in a building. Just as a door lets you into a building (possibly after security screening), an application entry point lets your requests in.

Think about a web application (see figure 1.1) running on the default HTTP port 80 on a server carrying the IP address 192.168.0.1. Port 80 on server 192.168.0.1 is an entry point to that web application. If the same web application accepts HTTPS requests on the same server on port 443, you have another entry point. When you have more entry points, you have more places to worry about securing. (You need to deploy more soldiers when you have a longer border to protect, for example, or to build a wall that closes all entry points.) The more entry points to an application, the broader the attack surface is.

Most monolithic applications have only a couple of entry points. Not every component of a monolithic application is exposed to the outside world and accepts requests directly.

In a typical Java Platform, Enterprise Edition (Java EE) web application such as the one in figure 1.1, all requests are scanned for security at the application level by a servlet filter.2 This security screening checks whether the current request is associated with a valid web session and, if not, challenges the requesting party to authenticate first.

Figure 1.1 A monolithic application typically has few entry points. Here, there are two: ports 80 and 443.

Further access-control checks may validate that the requesting party has the necessary permissions to do what they intend to do. The servlet filter (the interceptor) carries out such checks centrally to make sure that only legitimate requests are dispatched to the corresponding components. Internal components need not worry about the legitimacy of the requests; they can rightly assume that if a request lands there, all the security checks have already been done.

In case those components need to know who the requesting party (or user) is or to find other information related to the requesting party, such information can be retri-eved from the web session, which is shared among all the components (see figure 1.2). The servlet filter injects the requesting-party information into the web session during the initial screening process, after completing authentication and authorization.

Once a request is inside the application layer, you don’t need to worry about security when one component talks to another. When the Order Processing component talks to the Inventory component, for example, you don’t necessarily need to enforce any additional security checks (but, of course, you can if you need to enforce more granular access-control checks at the component level). These are in-process calls and in most cases are hard for a third party to intercept.

Figure 1.2 Multiple entry points (ports 80 and 443) are funneled to a single servlet filter. The filter acts as a centralized policy enforcement point.

In most monolithic applications, security is enforced centrally, and individual components need not worry about carrying out additional checks unless there is a desperate requirement to do so. As a result, the security model of a monolithic application is much more straightforward than that of an application built around microservices architecture.

1.2 Challenges of securing microservices

Mostly because of the inherent nature of microservices architecture, security is challenging. In this section, we discuss the challenges of securing microservices without discussing in detail how to overcome them. In the rest of the book, we discuss multiple ways to address these ...