Working on a process identity level:
When designing a new distributed system or refactor / enhance a monolithic application into microservices one thinks about the business app and processes by 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;
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. And this can be done in several ways, and there are a few open source tools that do it.
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;
o faster provisioning of code where those who wrote it, deploy it
o repeatable dev-sec-ops processes
o equal or improved security using QA security scan tools
o increases availability to the users,
o software level failover/resilience
o 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 in general 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. And 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 the CICD. This ensures that the microservice comes out of the CICD with an embedded identity that is cryptographically bonded to its memory. And then when the microservice is released to the production environment, the identity to used 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 its 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. And is 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 of doing different 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, weans 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 the monolith application the user identified/validated itself against the monolith, and 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 a 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 – xOps uses -Grafana where 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 xOps often recommends - 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 opensource and commercial solutions.