DevSecOps Using Container and Microservices Security

The responsibility and even accountability for security is rapidly shifting in the direction of DevOps engineers, as they have a view into the broad architecture of the processes and systems used to deploy microservices. Our customer discussions and xOps project engagements indicate that going forward, DevOps engineers and DevSecOps processes are going to be even more accountable for security. This trend should be a strong consideration, as good DevSecOps also makes application deployments, operations, and service monitoring easier, and more secure.

Working on a Process Identity Level

When designing a new distributed system or refactoring/enhancing a monolithic application into microservices, one thinks about the business app and processes by which each microservice communicates with other microservices. With that picture in mind, we have found – by working with clients and partners — that it makes more sense to provision the identities at that microservice level. The benefits are that: 

• This makes it easier to understand the distributed application process, as it typically does not change as frequently.
• It makes the most out of container orchestration agility because we don't need to restrict certain microservices to offer certain nodes. 
• It enables platforming, as the identities abstract the host identity that they are running on – whether a container, virtual machine, etc. 

Working Across Clouds, Domains, Machines, and Application Loads

Nevertheless, one of the biggest problems in this world of identities for microservices is propagated across multiple environments, compute types, and a hybrid cloud. The idea is that it is very hard to manage identities across those different environments if proprietary environments are involved because the distributed system is processing across different security and identity domains, and availability is more complex to manage, and dynamically scale up. 

xOps notes that there is evidence that many of the data breaches in large enterprises comes as a result of misunderstanding if the policy for security configuration of cloud services and systems is the function of the cloud provider, or the application owners, or lack of application of an existing configuration security policy. xOps DevOps ensures that the cloud configuration is secure before the microservices, can be deployed. 

The current approach at xOps is to use a single certificate authority across all environments, basically bringing your own certificate authority. This can be done in several ways, and there are a few open source tools that do it. For example:

• A service mesh can be, and in a growing number of our projects, is used as a certificate authority. Of course, service mesh system (legacy or “new”) have their own challenges to configure, but they are useful as a point of control for security and operations; our approach is to configure Istio across a few clusters of Kubernetes. Adding non-Kubernetes services to Istio opens the trust spectrum further but of course adds to the complexity of the configuration, it’s up to each project owner to determine the limits control authority. But given the complexity of operationalizing microservices, it’s a benefit as the application grows and operational control requires:
  
  
  1. faster provisioning of code where those who wrote it, deploy it
  2. repeatable dev-sec-ops processes
  3. equal or improved security using QA security scan tools 
  4. increases availability to the users, 
  5. software level failover/resilience
  6. rapid or dynamic scalability

Alternately, some customers choose to just use an inside identity. Or just a simple online certificate, and then of course synchronize those certificates across the different authorities in use across the distributed microservices landscape. This can be complex and is most used in customer environments where the DecSecOps processes and teams are experienced in microservices development, security, and operations management. xOps assesses customer maturity around DevSecOps processes and compute fabric and makes recommendations on the best approach. 

When customers implement an identity management and different entities, it is much easier to control and to understand, build, secure, configure, monitor, and trust your microservices. Trust in microservices in general, which is a key aspect of DevSecOps and DevOps, is a set of processes and architecture that defines how to authenticate microservices in this new distributed systems environment, whether Kubernetes is used or not. But the topic of microservices and protecting microservices the identity-based cloud workload is the opportunity and potential for successful DevOps. This also defines what is done to automatically create, manage, and secure workload identity and microservice entities and facilitate frictionless zero process security. 

Security Details in DevSecOps

The solution is to build a platform that creates an identity for every microservice as it goes through a CICD pipeline. This ensures that the microservice comes out of the pipeline with an embedded identity that is cryptographically bonded to its memory. Then, when the microservice is released to the production environment, the identity is used to automatically create security around it, using a policy. This helps to protect it against breeches and exploits, to make sure it communicates only with other approved and identified microservices, and only approved identified microservices access data. 

The practice functions as an automatic security layer that is added seamlessly via DevSecOps best practices right out of the CICD. To solve this challenge, and protect workloads right out of the CI/CD, xOps has partnered with Cyber Armor, a workload protection platform that creates the identity automatically as part of the CI/CD and continuously protects it when it is deployed 

Authentication means the ability to validate an identity against a certain entity. In Kubernetes, it's the default service account that applies to the entire cluster. In practice, it’s not typically used for microservices identity, unless a conscious decision (and configuration) is made to use that account for identity. And that's exactly what the service measurement control in Istio does. One can utilize it and make sure to use it as an identifier of the microservice, but it's not done by default. It's recommended to be taken care of it as part of your DevOps processes and provisioning systems. 

User Identity Versus Service Identity

Both users and microservices should be validated in your architecture. And the two of them have different challenges based on their respective solutions. 

Evolution from monolithic applications to microservices-based applications means that there are many more individual pieces of software running across or in the environment. And that is actually the gist of the security problem; the fact that you have all of those new components, each one of them can create an attack surface within your architecture, means that there is a constant need to validate that they are not compromised and that there are no unrecognized microservices in your environment.

User identity, again, this is a challenge as trust is validated or passed from microservice to microservice. Some customers enhance monolithic apps using microservices. If in a monolith application, a user identified/validated itself against the monolith, the monolith could decide what that user can do or cannot do. Now, the user identifies itself in front of the front-end microservices, but maybe this microservice here needs to decide based on the user, whether they can get to certain data or not. There is a need to propagate the identity of that user throughout the chain and be able to authenticate entitlement for that user, often deep within the architecture. At xOps, our approach is to use JSON web tokens together with frameworks such as AUTH0. 

Microservices Security in Sec Operations Management: Tools and Processes

In order to protect microservices, some of the attacks might not necessarily be from a user to user. It's simply just an attack on logic, application logic that is in this environment. This is where this constant scanning and comparison to “how it should be configured/built” comes in, where the goal is automatic discovery and application mapping, and expanding the application logic, and then adjusting the secure points accordingly so that we can secure against future attacks. When attacks are detected, they can be seen within – we use Grafana, so ops can see the graphs, and they show the different types of attack.

Additionally, if microservice based applications are protected by Radware app configuration management tools — that we often recommend — then when changes occur, those changes and exceptions to the configuration policy are feed into the Sec Ops for assessment and handling. When those changes are discovered, tools further examine the container registry, where Kubernetes is actually comparing that configuration image of the last state, and it logs the changes that have been discovered and can then be shared across all the different dev/ops teams for remediation.

xOps uses proven DevSecOps process, team education and collaboration, and skilled engineers to build or refactor distributed applications using microservices across multiple clouds, and on-premise customer private cloud resources using Azure or AWS service components combined with custom microservices/applications, and open-source and commercial solutions.