Although it’s possible to implement cloud migration by “lifting and shifting” applications and data from an on-premise data center to a replica environment on a cloud service, doing so doesn’t take advantage of all the benefits cloud computing has to offer, such as automatic resource scaling. Exploiting these features means not only reconfiguring the application architecture but also often re-developing the application code. Coding applications to take advantage of the cloud environment is known as cloud-native development.

One downside of cloud-native development is that it’s quite a bit more complex than traditional application development. And this increase in complexity is accompanied by an increase in the difficulty of implementing robust security for cloud-based applications.

In this article we discuss the basics of cloud-native security and some of the challenges that cloud developers and architects face, in particular those challenges related to Kubernetes clusters.

The 4 “Cs” of Cloud Security

Security for a cloud computing environment is typically organized into four layers, with each layer nested inside another. These layers, from innermost to outermost, are:

• Code: Security that is built into the application code. This is the layer that client organizations have the most control over, and the one that most resembles traditional security coding against attacks such as SQL injections, cross-site scripting, and cross-site request forgery. 
• Container: Security measures that are defined in each container image. Security at this layer is most concerned with mitigating vulnerable images, updating services and frameworks, using trusted base images, and incorporating appropriate security measures (e.g. Do Not Use ROOT privilege in a DockerFile).
• Cluster: Security defined for the Kubernetes cluster. In this layer, security focuses on the cluster nodes, control plane, data, and container segmentation in the cluster, RBAC, and data encryption.
• Cloud: Security defined for the physical or virtual servers that host the Kubernetes clusters. Although the cloud service provider is responsible for making security available at this layer, it’s up to the client organization to implement and configure them appropriately (e.g. IAM, KMS etc)

Each layer’s security is built upon the foundation of the security of the next outer layer. However, a serious security flaw in any layer can cause potential exploitation, so each layer is equally important to the overall system security.

Kubernetes Cluster Security Challenges

The three areas of concern for securing a Kubernetes cluster are:

• Components: Controlling access to API servers and cluster control plane.
• Services: Configuring and controlling access to services running in the cluster, with appropriate RBAC, authentication, and authorization of service accounts
• Networking: Network segmentation using namespaces and node affinities, and encryption of communication among services and cluster components

Each of these areas must be secured on its own and with reference to the other areas. Doing so requires a holistic approach to security and proper application of best practices.

Sound complex? It is. However, the beast can be tamed with the knowledge, skills, discipline, and repeatable processes that define an experienced, professional team. At MicroStack, our experts have been designing and securing cloud environments for years. Contact us today to learn how we can set up your cloud environment for high performance and maximum security.

‍