SAP Business Application Studio (a.k.a. BAS) is a modern development environment that enables developers to easily build and extend SAP solutions, seamlessly integrating SAP services, technologies, and solutions.
As an SAP product, it is designed to offer an Enterprise-Grade Security solution.
In this blog post, I will describe some of the different Kubernetes (K8S) security patterns and industry best practices that are implemented in SAP Business Application Studio for users that want to understand how it is done under the hood.
Note: I will not cover all the security aspects in this blog post, I will share a subset of them. As an SAP Business Application Studio is an Enterprise Product, we constantly reinvestigate and reevaluate it, including the new features and according to industry standards.
What is a Dev Space?
A dev space is a K8S Pod that contains everything a developer needs. It is accessible through a browser. It includes development tools, command-line terminal, file system for source code and binaries, build-tools, and runtime environments for debugging and execution of developed code. Dev spaces can be extended with additional functionality.
The dev space Pod runs multiple containers that need to work together.
Dev space components such as tools for developing multitarget applications (a.k.a. MTA tools) and SAP Fiori tools are delivered as extension containers.
They can be added or removed for scenario flexibility.
A dev space also supports docker-less VSIX extensions which comply with VS Code extensions and run in the IDE Core container. The dev space core IDE is based on Eclipse Theia (a VS Code compliant open-source) as an extensible platform IDE.
Dev Space Isolation
Network
A user can run different applications for development purposes in his dev space. Running different applications on the same Kubernetes cluster creates the risk of lateral movement between an exploited application to other applications deployed in the same cluster. Network segmentation is important to ensure that containers can communicate only with those they are supposed to.
By applying Pod-level firewall rules, the communication between different dev space Pods is not allowed. This prevents undesired interactions between different dev spaces and the applications running in them and effectively isolates them from each other.
Host
SAP Business Application Studio dev spaces run with a non-root user as a form of in-depth-defense to make attacks against the node’s root user much more difficult.
Worker Group
Dev space Pods and System Pods (managing dev space Pods) do not share the same node. This is achieved by separating the nodes into different groups called worker groups. This creates an isolation of the dev space from the System Pods that run in the cluster. In this way, any resource consumption created by a dev space cannot affect the functionality of the system components.
Pod Limited Resources
Each dev space can use limited resources (such as CPU and memory) to protect the system from abuse and make sure the users have enough resources to ensure good performance and system response.
Respectively, each dev space has a limited file system persistent storage size to prevent abuse of the available storage.
Dev Space Container Isolation
An SAP Business Application Studio dev space has several docker-based containers.
All the incoming traffic goes through a trusted container which validates the user authorization before routing the traffic to a process running in the dev space, for example, the Core IDE. The user gets access to an IDE process running in a container. This container cannot access sensitive data stored by other containers in non-shared locations.
No comments:
Post a Comment