Shulou(Shulou.com)06/03 Report--

This is the second in a three-part series on Kubernetes security. In the previous article we shared how to protect your Kubernetes cluster from external threats, in this article we will share three ways to protect Kubernetes from internal threats, and later we want to explain how to deal with resource consumption or noisy neighbor problems.

Essentially, Kubernetes clusters are multi-user. As a result, organizations often want to ensure cross-traffic is protected through RBAC (Role-Based Access Control), logical isolation, and network policies.

Container orchestration systems like Kubernetes bring developers and operations people (DevOps) closer together, making it easier for teams to collaborate effectively with each other. True, we believe that most members of the DevOps team have no malicious intent, but organizations still need to ensure that if there is cross-communication between applications and if someone writes bad code, we can minimize the damage.

Role-based access control mitigates malicious threats to containers and protects physical servers differently. However, whether a system administrator deploys multiple servers in a data center or virtual clusters in Kubernetes, role-based access control (RBAC) is a critical security initiative.

Adrian Goins, Senior Solutions Architect at Rancher Labs, says,"Internally, you want to have some sort of role-based access control, following the rules of least privilege. "Rancher Labs has developed Rancher, a complete container management platform for Kubernetes.

"You only allow users and service accounts access to resources they need to access, and access rights only apply to whatever they need to do. "This access control extends down to not having to use root privileges to run container processes.

Rancher interacts with multiple backend providers of RBAC, simplifying the process for Kubernetes users. For example, system administrators can deploy Rancher and go to the authentication tab to import their organization's Microsoft Active Directory data into Kubernetes. Rancher immediately extracts all users and groups from Activate Directory, which can now be used in roles and then applied to all clusters managed by Rancher.

Typically, administrators must manually configure these roles and replicate them in each cluster. For an organization with one or two clusters, this may not be a problem, but if a company has dozens, hundreds, or more clusters, the likelihood of human error is very high. There is always something missing, and the consequences can be disastrous.

Rancher enables administrators to centralize roles across clusters, drilling down to give users access to specific clusters that can only perform specific tasks. If an employee leaves, just deactivate their account in Active Directory. It's easy. Once this is done, the deactivated account immediately loses access to each cluster. Because Rancher acts as an authentication agent for each cluster, administrators no longer need to provide or manage accounts for each provider where the cluster is deployed.

02 Logical isolation using namespaces

In addition, applications deployed to clusters should use namespaces to logically isolate resources and allow administrators to attach security policies to them. Namespaces can segment cluster resources and include quotas for the pods they contain and default resource limits. Although namespaces were originally intended for use in multi-user environments across multiple teams or projects, they are now recognized as standard best practices within clusters.

By default, in Kubernetes, nothing prevents two different teams that own containers from having a conversation. However, Kubernetes 'RBAC capability limits this communication.

"We can say that containers in my namespace can only communicate with containers in the same namespace and are not allowed to communicate with containers in other namespaces. Goins says, moreover,"I'm only allowed to talk to my own namespace as a user, so to speak, and you're only allowed to talk to your own namespace as a user." This is workload level as well as user level security. If done correctly, users won't even see the presence of another workload. "

This is one of the features of Kubernetes-multi-tenant in a single cluster. However, Rancher extends namespace functionality further by consolidating "project" resources to help ease the administrative burden of clusters.

In Rancher, Projects allows administrators to collect multiple namespaces under a single entity. In the base version of Kubernetes, features such as RBAC or cluster resources were assigned to individual namespaces. In some Kubernetes clusters, multiple namespaces require the same access rights, and manually assigning these permissions to each namespace can be a tedious task. Even if all namespaces require the same permissions, there is no guarantee that those permissions will apply to all namespaces in a single operation. Goins points out that administrators must repeatedly assign these permissions to each namespace.

Rancher's Project concept solves this problem by allowing administrators to assign resources and access rights at the project level. Each namespace in the project then inherits these resources and policies, so the administrator only needs to assign them to the project once, rather than assigning them to each namespace.

With Project, administrators can perform many actions, such as assigning users access to a set of namespaces, assigning users to specific roles in the project, assigning resources to the project, assigning pod security policies, and so on.

03 NetworkPolicy Resources

NetworkPolicy is a Kubernetes resource that configures how pods (logical groups of one or more containers with shared storage and network resources) communicate with each other or with other network endpoints.

By default, pods are non-isolated, meaning they accept traffic from any source. Goins explains,"NetworkPolicy is like a software-based firewall between pods running on a Kubernetes cluster. Administrators can create a 'default' isolation policy for namespaces by first creating a NetworkPolicy that selects all pods but does not allow any incoming or outgoing traffic to be sent to those pods. "

In addition, administrators can configure which pods can connect to each other. These policies can be further elaborated, allowing administrators to specify which namespaces can communicate, or select port numbers to enforce each policy.

NetworkPolicy resources require a network backend that supports configuration, such as Calico, Canal, Romana, or Weave. According to Kubernetes documentation, simply creating a resource without a controller to implement it is ineffective.

04 Preventing Internal Threats

Although there are some default tools to secure Kubernetes, many of them seem to be designed solely to prevent external threats from reaching the cluster. What's more, they're hard to scale. When an enterprise wants to protect its cluster from insider threats, whether from actual malicious insider threats or simply to prevent the propagation of errors or miscodes, it has very few defenses.

Fortunately, however, there are a number of solutions that are already focused on protecting clusters from unauthorized internal access. Some of these exist in the Kubernetes framework, such as namespaces, while Rancher's Project extends beyond the default settings for more precise management and control of the entire enterprise environment.

The key is not to give up or get discouraged on the cybersecurity of internal resources. By following the three steps in this article, you can still get the most out of Kubernetes clustering while maintaining tight control over internal access protection.

In the next article, which will be the last in this series, we'll look at how to handle resource constraints and how to prevent users from over-consuming Kubernetes resources.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.