micro segmentation technology

Zero Trust Security Strategy

by Publications

 

zero trust security strategy

 

Zero Trust Security Strategy

In this fast-paced digital era, where cyber threats are constantly evolving, traditional security measures alone are no longer sufficient to protect sensitive data. This is where the concept of Zero Trust Security Strategy comes into play. In this blog post, we will delve into the principles and benefits of implementing a Zero Trust approach to safeguard your digital assets.

Zero Trust Security is a comprehensive and proactive security model that challenges the traditional perimeter-based security approach. Instead of relying on a trusted internal network, Zero Trust operates on the principle of “never trust, always verify.” It requires continuous authentication, authorization, and strict access controls to ensure secure data flow throughout the network.

Highlights: Zero Trust Security Design

Networks are Complex

Today’s networks are complex beasts, and considering yourself an entirely zero trust network design is a long journey. It means different things to different people. Networks these days are heterogeneous, hybrid, and dynamic. Over time, technologies have been adopted, from punch card coding to the modern-day cloud, container-based virtualization, and distributed microservices.

This complex situation leads to a dynamic and fragmented network along with fragmented processes. The problem is that enterprises over-focus on connectivity without fully understanding security. Just because you connect does not mean you are secure.

Rise in Security Breaches

Unfortunately, this misconception may allow the most significant breaches. As a result, those who can move towards a zero-trust environment with a zero-trust security strategy provide the ability to enable some new techniques that can help prevent breaches, such as zero trust and microsegmentation, zero trust networking along with Remote Browser Isolation technologies that render web content remotely. 

 

Related: For pre-information, you may find the following posts helpful:

  1. Identity Security
  2. Technology Insight For Microsegmentation
  3. Network Security Components

 



Zero Trust and Microsegmentation

Key Zero Trust Security Strategy Discussion points:


  • People overfocus on connectivity and forget security.

  • Control vs visibilty.

  • Starting a data-centric model.

  • Automation and Orchestration.

  • Starting a Zero Trust security journey.

 

Back to basics with the Zero Trust Security Design

Traditional perimeter model

The security zones are formed with a firewall/NAT device between the internal network and the internet. There is the internal “secure” zone, the DMZ (also known as the demilitarized zone), and the untrusted zone (the internet). If this organization needed to interconnect with another at some point in the future, a device would be placed on that boundary similarly. The neighboring organization will likely become a new security zone, with particular rules about traffic going from one to the other, just like the DMZ or the secure area.

 

 Key Components of Zero Trust

To effectively implement a Zero Trust Security Strategy, several crucial components need to be considered. These include:

1. Identity and Access Management (IAM): Implementing strong IAM practices ensures that only authenticated and authorized users can access sensitive resources.

2. Microsegmentation: By dividing the network into smaller segments, microsegmentation limits lateral movement and prevents unauthorized access to critical assets.

3. Least Privilege Principle: Granting users the least amount of privileges necessary to perform their tasks minimizes the risk of unauthorized access and potential data breaches.

Advantages of Zero Trust Security

Adopting a Zero Trust Security Strategy offers numerous benefits for organizations:

1. Enhanced Security: Zero Trust ensures a higher level of security by continually verifying and validating access requests, reducing the risk of insider threats and external breaches.

2. Improved Compliance: With stringent access controls and continuous monitoring, Zero Trust aids in meeting regulatory compliance requirements.

3. Reduced Attack Surface: Microsegmentation and strict access controls minimize the attack surface, making it harder for cybercriminals to exploit vulnerabilities.

Challenges and Considerations

While Zero Trust Security Strategy offers great potential, its implementation comes with challenges. Some factors to consider include:

1. Complexity: Implementing Zero Trust can be complex, requiring careful planning, collaboration, and integration of various security technologies.

2. User Experience: Striking a balance between security and user experience is crucial. Overly strict controls may hinder productivity and frustrate users.

 

Zero trust and microsegmentation 

The concept of zero trust and micro segmentation security allows organizations to execute a Zero Trust model by erecting secure micro-perimeters around distinct application workloads. Organizations can eliminate zones of trust that increase their vulnerability by acquiring granular control over their most sensitive applications and data. It enables organizations to achieve a zero-trust model and helps ensure the security of workloads regardless of where they are located.

 

Control vs. visibility

Zero trust and microsegmentation overcome this with an approach that provides visibility over the network and infrastructure to ensure you follow security principles such as least privilege. Essentially, you are giving up control but also gaining visibility. This provides the ability to understand all the access paths in your network. 

For example, within a Kubernetes environment, administrators probably don’t know how the applications connect to your on-premises data center or get Internet connectivity visibility. Hence, one should strive to give up control for visibility to understand all the access paths. Once all access paths are known, you need to review them consistently in an automated manner.

 

zero trust security strategy
Diagram: Zero trust security strategy. The choice of control over visibility.

 

Zero Trust Security Strategy

The move to zero trust security strategy can assist in gaining the adequate control and visibility needed to secure your networks. However, it consists of a wide spectrum of technologies from multiple vendors. For many, embarking on a zero trust journey is considered a data- and identity-centric approach to security instead of what we initially viewed as a network-focused journey.  

 

Zero Trust Security Strategy: Data-Centric Model

Zero trust and microsegmentation

In pursuit of zero trust and microsegmentation, abandoning traditional perimeter-based security and focusing on the zero trust reference architecture and its data is recommended. One that understands and maps data flows can then create a micro perimeter of control around their sensitive data assets to gain visibility into how they use data. Ideally, you need to identify your data and map its flow. Many claims that zero trust starts with the data. And the first step to building a zero trust security architecture is identifying your sensitive data and mapping its flow.

We understand that you can’t protect what you cannot see; gaining the correct visit of data and understanding the data flow is critical. However, securing your data, even though it is the most crucial step, may not be your first zero trust step. Why? It’s a complex task.

 

zero trust environment
Diagram Data: Zero trust environment. The importance of data.

 

Start a zero trust security strategy journey

For a successful Zero Trust Network ZTN, I would start with one aspect of zero trust as a project recommendation. And then work your way out from there. When we examine implementing disruptive technologies that are complex to implement, we should focus on outcomes, gain small results and then repeat and expand.

 

  • A key point. Zero trust automation

This would be similar to how you may start an automation journey. Rolling out automation is considered risky. It brings consistency and a lot of peace of mind when implemented correctly. But simultaneously, if you start with advanced automation use cases, there could be a large blast radius.

As a best practice, I would start your automation journey with config management and continuous remediation. And then move to move advanced use cases throughout your organization. Such as edge networking, full security ( Firewall, PAM, IDPS, etc.), and CI/CD integration.

 

  • A key point: You can’t be 100% zero trust

It is impossible to be 100% secure. You can only strive to be as secure as possible without hindering agility. It is similar to that of embarking on a zero-trust project. It is impossible to be 100% zero trust as this would involve turning off everything and removing all users from the network. We could use single-packet authorization without sending the first packet! 

 

Do not send a SPA packet

When doing so, we would keep the network and infrastructure dark without sending the first SPA packet to kick off single-packet authentication. However, lights must be on, services must be available, and users must access the services without too much interference. Users expect some downtime. Nothing can be 100% reliable all of the time.

Then you can balance velocity and stability with practices such as Chaos Engineering Kubernetes. But users don’t want to hear of a security breach.

 

zero trust journey
Diagram: Zero trust journey. What is your version of trust?

 

  • A key point. What is trust?

So the first step toward zero trust is to determine a baseline. This is not a baseline for network and security but a baseline of trust. And zero trust is different for each organization, and it boils down to the level of trust; what level does your organization consider zero trust?  What mechanism do you have in place?

There are many avenues of correlation and enforcement to reach the point where you can call yourself a zero trust environment. It may never become a zero trust environment but is limited to certain zones, applications, and segments that share a standard policy and rule base.

 

  • A key point: Choosing the vendor

Also, can zero trust security vendors be achieved with a single vendor regarding vendor selection? No one should consider implementing zero trust with one vendor solution. However, many zero trust elements can be implemented with a SASE definition known as Zero Trust SASE.

In reality, there are too many pieces to a zero-trust project, and not one vendor can be an expert on them. Once you have determined your level of trust and what you expect from a zero-trust environment, you can move to the main zero-trust element and follow the well-known zero-trust principles. Firstly, automation and orchestration. You need to automate, automate and automate.

 

zero trust reference architecture
Diagram: Zero trust reference architecture.

 

Zero Trust Security Strategy: The Components

Automation and orchestration

Zero trust is impossible to maintain without automation and orchestration. Firstly, you need to have identification of data along with access requirements. All of this must be defined along with the network components and policies. So if there is a violation, here is how we reclaim our posture without human intervention. This is where automation comes to light; it is a powerful tool in your zero trust journey and should be enabled end-to-end throughout your enterprise.

An enterprise-grade zero trust solution must work quickly with the scaling ability to improve the automated responses and reactions to internal and external threats. The automation and orchestration stage defines and manages the micro perimeters to provide the new and desired connectivity. Ansible architecture consists of Ansible Tower and the Ansible Core based on the CLI for a platform approach to automation.

 

Zero trust automation

With the matrix of identities, workloads, locations, devices, and data continuing to grow more complicated, automation provides a necessity. And you can have automation in different parts of your enterprise and at different levels. 

You can have pre-approved playbooks stored in a Git repository that can be version controlled with a Source Control Management system (SCM). Storing playbooks in a Git repository puts all playbooks under source control, so everything is better managed.

Then you can use different security playbooks already approved for different security use cases. Also, when you bring automation into the zero-trust environments, the Ansible variables can separate site-specific information from the playbooks. This will be your playbooks more flexible. You can also have a variable specific to the inventory known as the Ansible inventory variable.

 

  • Schedule zero trust playbooks under version control

For example, you can kick off a playbook to run at midnight daily to check that patches are installed. If there is a deviation from a baseline, the playbook could send notifications to relevant users and teams.

 

Ansible Tower: Delegation of Control

I use Ansible Tower, which has a built-in playbook, scheduling, and notifications for many of my security baselines. I can combine this with the “check” feature so less experienced team members can run playbook “sanity” checks and don’t have the need or full requirement to perform change tasks.

Role-based access control can be tightly controlled for even better delegation of control. You can integrate Ansible Towers with your security appliances for advanced security uses. Now we have tight integration with security and automation. Integration is essential; unified automation approaches require integration between your automation platform and your security technologies. 

 

Security integration with automation

For example, we can have playbooks that automatically collect logs for all your firewall devices. These can be automatically sent back to a log storage backend for analysts, where machine learning (ML) algorithms can perform threat hunting and examine for any deviations.

Also, I find Ansible Towers workflow templates handy and can be used to chain different automation jobs into one coherent workflow. So now we can chain different automation events together. Then you can have actions based on success, failure, or always.

 

  • A key point – Just alert and not block

You could just run a playbook to raise an alert. It does not necessarily mean you should block. I would only block something when necessary. So we are using automation to instantiate a playbook to bring those entries that have deviated from the baseline back into what you consider to be zero trust. Or we can automatically move an endpoint into a sandbox zone. So the endpoint can still operate but with less access. 

Consider that when you first implemented the network access control (NAC), you didn’t block everything immediately; you allowed it to bypass and log in for some time. From this, you can then build a baseline. I would recommend the same thing for automation and orchestration. When I block something, I recommend human approval to the workflow.

 

zero trust automation
Diagram: Zero trust automation. Adaptive access.

 

Zero Trust Least Privilege, and Adaptive Access

Enforcement points and flows

As you build out the enforcement points, it can be yes or no. Similar to the concept of the firewall’s binary rules, they are the same as some of the authentication mechanisms work. However, it would be best to monitor anomalies regarding things like flows. You must stop trusting packets as if they were people. Instead, they must eliminate the idea of trusted and untrusted networks. 

 

Identity centric design

Rather than using IP addresses to base policies on, zero trust policies are based on logical attributes. This ensures an identity-centric design around the user identity, not the IP address. This is a key component of zero trust, how you can have adaptive access for your zero trust versus a simple yes or no. Again, following a zero trust identity approach is easier said than done. 

 

  • A key point: Zero trust identity approach

With a zero trust identity approach, the identity should be based on logical attributes, for example, the multi-factor authentication (MFA), transport layer security (TLS) certificate, the application service, or the use of a logical label/tag. Tagging and labeling are good starting points as long as those tags and labels make sense when they flow across different domains. Also, consider the security controls or tagging offered by different vendors.

How do you utilize the different security controls from different vendors, and more importantly, how do you use them adjacent to one another? For example, Palo Alto utilizes an App-ID, a patented traffic classification system. Please keep in mind vendors such as Cisco have end-to-end tagging and labeling when you integrate all of their products, such as the Cisco ACI and SD-Access.

Zero trust environment and adaptive access

Adaptive access control uses policies that allow administrators to control user access to applications, files, and network features based on multiple real-time factors. Not only are there multiple factors to consider, but these are considered in real-time. What we are doing is responding to potential threats in real-time by continually monitoring user sessions for a variety of factors. We are not just looking at IP or location as an anchor for trust.

 

  • Pursue adaptive access

Anything tied to an IP address is useless. Adaptive access is more of an advanced zero trust technology, likely later in the zero trust journey. Adaptive access is not something you would initially start with.

 

Micro segmentation and zero trust security
Diagram: Micro segmentation and zero trust security.

 

Zero Trust and Microsegmentation 

VMware introduced the concept of microsegmentation to data center networking in 2014 with VMware NSX micro-segmentation. And it has grown in usage considerably since then. It is challenging to implement and requires a lot of planning and visibility.

Zero trust and microsegmentation security enforce the security of a data center by monitoring the flows inside the data center. The main idea is that in addition to network security at the perimeter, data center security should focus on the attacks and threats from the internal network.

 

Small and protected isolated sections

With zero trust and microsegmentation security, the traffic inside the data center is differentiated into small isolated parts, i.e., micro-segments depending on the traffic type and sensitivity level. A strict micro-granular security model that ties security to individual workloads can be adopted.

Security is not simply tied to a zone; we are going to the workload level to define the security policy. By creating a logical boundary between the requesting resource and protected assets, we have minimized lateral movement elsewhere in the network, gaining east-west segmentation.

 

Zero trust and microsegmentation

It is often combined with micro perimeters. By shrinking the security perimeter of each application, we can control a user’s access to the application from anywhere and any device without relying on large segments that may or may not have intra-segment filtering.

 

  • Use case: Zero trust and microsegmentation:  5G

Micro segmentation is the alignment of multiple security tooling along with aligning capabilities with certain policies. One example of building a micro perimeter into a 5G edge is with containers. The completely new use cases and services included in 5G bring large concerns as to the security of the mobile network. Therefore, require a different approach to segmentation.

 

Micro segmentation and 5G

In a 5G network, a micro segment can be defined as a logical network portion decoupled from the physical 5G hardware. Then we can chain several micro-segments chained together to create end-to-end connectivity that maintains application isolation. So we have end-to-end security based on micro segmentation, and each micro segment can have fine-grained access controls.

 

  • A key point: Zero trust and microsegmentation: The solutions

A significant proposition for enabling zero trust is micro segmentation and micro perimeters. Their use must be clarified upfront. Essentially, their purpose is to minimize and contain the breach (when it happens). Rather than using IP addresses to base segmentation policies, the policies are based on logical constructs. Not physical attributes. 

 

Monitor flows and alert

Ideally, favor vendors with micro segmentation solutions that monitor baseline flows and alert on anomalies. These should also assess the relative level of risk/trust and alert on anomalies.  They should also continuously assess the relative level of risk/trust on the network session behavior observed. This may include unusual connectivity patterns, excessive bandwidth, excessive data transfers, and communication to URLs or IP addresses with a lower level of trust. 

 

Micro segmentation in networking

The level of complexity comes down to what you are trying to protect. This can be something on the edges, such as a 5G network point, IoT, or something central to the network. Both of which may need physical and logical separation. A good starting point for your micro segmentation journey is to build a micro segment but not in enforcement mode. So you are starting with the design but not implementing it fully. The idea is to watch and gain insights before you turn on the micro segment.

 

Containers and Zero Trust

Let us look at a practical example of applying the zero trust principles to containers. There are many layers within the container-based architecture to which you can apply zero trust. For communication with the containers, we have two layers. Nodes and services in the containers with a service mesh type of communication with a mutual TLS type of solutions. 

The container is already a two-layer. We have the nodes and services. The services communicate with an MTLS solution to control the communication between the services. Then we have the application. The application overall is where you have the ingress and egress access points. 

Docker container security

 

The OpenShift secure route

OpenShift networking SDN is similar to a routing control platform based on Open vSwitch that operates with the OVS bridge programmed with OVS rules. OVS networking has what’s known as a route construct. These routes provide access to specific services. Then, the service acts as a software load balancer to the correct pod. So we have a route construct that sits in front of the services. This abstraction layer and the OVS architecture bring many benefits to security.

 

openshift sdn
Diagram: Openshift SDN.

 

The service is the first level of exposing applications, but they are unrelated to DNS name resolution. To make servers accepted by FQDN, we use the OpenShift route resource, and the route provides the DNS. In Kubernetes’s words, we use Ingress, which exposes services to the external world. However, in Openshift, it is a best practice to use a routing set. Routes are an alternative to Ingress.

 

OpenShift security: OpenShift SDN and the secure route 

One of the advantages of the OpenShift route construct is that you can have secure routes. Secure routes provide advanced features that might not be supported by standard Kubernetes Ingress controllers, such as TLS re-encryption, TLS passthrough, and split traffic for blue-green deployments. 

Securing containerized environments is considerably different from securing the traditional monolithic application because of the inherent nature of the microservices architecture. A monolithic application has few entry points, for example, ports 80 and 443. 

Not every monolithic component is exposed to external access and must accept requests directly. Now with a secure openshift route, we can implement security where it matters most and at any point in the infrastructure. 

 

Context Based Authentication

For zero trust, it depends on what you can do with the three different types of layers. The layer you want to apply zero trust depends on the context granularity. For context-based authentication, you need to take in as much context as possible to make access decisions, and if you can’t, what are the mitigating controls?

You can’t just block. We have identity versus the traditional network-type parameter of controls. If you cannot rely on the identity and context information, you rely on and shift to network-based controls as we did initially. Network-based controls have been around for decades and create holes in the security posture. 

However, suppose you are not at a stage to implement access based on identity and context information. In that case, you may need to keep the network-based control and look deeper into your environment where you can implement zero trust to regain a good security posture. This is a perfect example of why you implement zero trust in isolated areas.

 

  • Examine zero trust layer by layer.

So it would help if you looked layer by layer for specific use cases and then at what technology components you can apply zero trust principles. So it is not a question of starting with identity or micro segmentation. The result should be a combination of both. However, identity is the critical jewel to look out for and take in as much context as possible to make access decisions and keep threats out. 

 

Take a data-centric approach. Zero trust data

Gaining visibility into the interaction between users, apps, and data across many devices and locations is imperative. This allows you to set and enforce policies irrespective of location. A data-centric approach takes location out of the picture. It comes down to “WHAT,” which is always the data. What are you trying to protect? So you should build out the architecture method over the “WHAT.”

 

Zero Trust Data Security

  • Step 1: Identify your sensitive data 

You can’t protect what you can’t see. Everything managed desperately within a hybrid network needs to be fully understood and consolidated into a single console. Secondly, once you know how things connect, how do you ensure they don’t reconnect through a broader definition of connectivity?

You can’t just rely on IP addresses anymore to implement security controls. So here, we need to identify and classify sensitive data. By defining your data, you can identify sensitive data sources to protect. Next, simplify your data classification. This will allow you to segment the network based on data sensitivity. When creating your first zero trust micro perimeter, start with a well-understood data type or system.

 

  • Step2: Zero trust and microsegmentation

Micro segmentation software that segments the network based on data sensitivity  

Secondly, you need to segment the network based on data sensitivity. Here we are defining a micro perimeter around sensitive data. Once you determine the optimal flow, identify where to place the micro perimeter.  Remember that virtual networks are designed to optimize network performance; they can’t prevent malware propagation, lateral movement, or unauthorized access to sensitive data. Like the VLAN, it was used for performance but became a security tool.

 

A final note: Firewall micro segmentation

Enforce micro perimeter with physical or virtual security controls. There are multiple ways to enforce micro perimeters. For example, we have NGFW from a vendor like Check Point, Cisco, Fortinet, or Palo Alto Networks.  If you’ve adopted a network virtualization platform, you can opt for a virtual NGFW to insert into the virtualization layer of your network. You don’t always need an NGFW to enforce network segmentation; software-based approaches to microsegmentation are also available.

 

Conclusion:

In conclusion, Zero Trust Security Strategy is an innovative and robust approach to protect valuable assets in today’s threat landscape. By rethinking traditional security models and enforcing strict access controls, organizations can significantly enhance their security posture and mitigate risks. Embracing a Zero Trust mindset is a proactive step towards safeguarding against ever-evolving cyber threats.

 

OpenShift Security Context Constraints

OpenShift Security Best Practices

by Blog

OpenShift Security Best Practices

In today's digital landscape, where cybersecurity threats are becoming increasingly sophisticated, it is imperative to prioritize the security of your Openshift environment. By implementing best practices and following industry standards, you can enhance the security posture of your Openshift deployment. In this blog post, we will explore key security measures and guidelines that will help safeguard your Openshift environment.

Matt Conran

To establish a solid foundation for Openshift security, it is crucial to ensure the security of your underlying infrastructure. This includes implementing robust network security measures, using secure access controls, and regularly patching and updating your infrastructure components. By proactively addressing potential vulnerabilities, you can mitigate risks and protect your Openshift environment.

Once your infrastructure is secure, it is essential to focus on hardening your Openshift cluster. This involves restricting privileged access, implementing secure authentication mechanisms such as two-factor authentication, and configuring role-based access controls (RBAC) to enforce granular access permissions. Additionally, regularly auditing and monitoring your cluster can help identify and respond to any suspicious activities promptly.

Table of Contents

Highlights: OpenShift Security

Stricter Securit than Kubernetes

OpenShift has stricter security policies than Kubernetes. For instance, it is forbidden to run a container as root. It also offers a secure-by-default option to enhance security. Kubernetes doesn’t have built-in authentication or authorization capabilities, so developers must manually create bearer tokens and other authentication procedures.

OpenShift provides a range of security features, including role-based access control (RBAC), image scanning, and container isolation, that help ensure the safety of containerized applications.

Related: For useful pre-information on OpenShift basics, you may visit the following posts helpful:

  1. OpenShift Networking
  2. Kubernetes Security Best Practice
  3. Container Networking
  4. Identity Security
  5. Docker Container Security
  6. Load Balancing



OpenShift Security.

Key Observability Security Best Practices points:


  • The traditional fixed stack security architecture. 

  • Microservices: Many different entry points.

  • Docker container attack vectors.

  • Security Context Constraints.

  • OpenShift network security.

Back to Basics: Starting OpenShift Security with OpenShift Best Practices

Generic: Securing containerized environments

Securing containerized environments is considerably different from securing the traditional monolithic application because of the inherent nature of the microservices architecture. We went from one to many, and there is a clear difference in attack surface and entry points. So there is much to consider for OpenShift network security and OpenShift security best practices, including many Docker security options.

The application stack previously had very few components, maybe just a cache, web server, and database separated and protected by a context firewall. The most common network service allows a source to reach an application, and the sole purpose of the network is to provide endpoint reachability.

As a result, the monolithic application has few entry points, for example, ports 80 and 443. Not every monolithic component is exposed to external access and must accept requests directly. And we designed our networks around these facts. The following diagram provides information on the threats you must consider for container security.

container security
Diagram: Container security. Source Neuvector

1. Secure Authentication and Authorization: One of the fundamental aspects of OpenShift security is ensuring that only authorized users have access to the platform. Implementing robust authentication mechanisms, such as multifactor authentication (MFA) or integrating with existing identity management systems, is crucial to prevent unauthorized access. Additionally, defining fine-grained access controls and role-based access control (RBAC) policies will help enforce the principle of least privilege.

2. Container Image Security: OpenShift leverages containerization technology, which brings its security considerations. It is essential to use trusted container images from reputable sources and regularly update them to include the latest security patches. Implementing image scanning tools to detect vulnerabilities and malware within container images is also recommended. Furthermore, restricting privileged containers and enforcing resource limits will help mitigate potential security risks.

3. Network Security: OpenShift supports network isolation through software-defined networking (SDN). It is crucial to configure network policies to restrict communication between different components and namespaces, thus preventing lateral movement and unauthorized access. Implementing secure communication protocols, such as Transport Layer Security (TLS), between services and enforcing encryption for data in transit will further enhance network security.

4. Monitoring and Logging: A robust monitoring and logging strategy is essential for promptly detecting and responding to security incidents. OpenShift provides built-in monitoring capabilities, such as Prometheus and Grafana, which can be leveraged to monitor system health, resource usage, and potential security threats. Additionally, enabling centralized logging and auditing of OpenShift components will help identify and investigate security events.

5. Regular Vulnerability Assessments and Penetration Testing: To ensure the ongoing security of your OpenShift environment, it is crucial to conduct regular vulnerability assessments and penetration testing. These activities will help identify any weaknesses or vulnerabilities within the platform and its associated applications. Addressing these vulnerabilities promptly will minimize the risk of potential attacks and data breaches.

OpenShift Security

OpenShift delivers all the tools you need to run software on top of it with SRE paradigms, from a monitoring platform to an integrated CI/CD system that you can use to monitor and run both the software deployed to the OpenShift cluster, as well as the cluster itself. So, the cluster needs to be secured along with the workload that runs in the cluster. 

From a security standpoint, OpenShift provides robust encryption controls to protect sensitive data, including platform secrets and application configuration data. In addition, OpenShift optionally utilizes FIPS 140-2 Level 1 compliant encryption modules to meet security standards for U.S. federal departments.

This post highlights OpenShift security and provides security best practices and considerations when planning and operating your OpenShift cluster. These will give you a starting point. However, as clusters, as well as bad actors, are ever-evolving, it is of significant importance to revise the steps you took.

 

Central security architecture

Therefore, we often see security enforcement in a fixed central place in the network infrastructure. This could be, for example, a significant security stack consisting of several security appliances. We are often referred to as a kludge of devices. As a result, the individual components within the application need not worry about carrying out any security checks as they occur centrally for them.

On the other hand, with the common microservices architecture, those internal components are specifically designed to operate independently and accept requests alone, which brings considerable benefits to scaling and deploying pipelines.

However, each component may now have entry points and accept external connections. Therefore, they need to be concerned with security individually and not rely on a central security stack to do this for them.

OpenShift Security Guide
Diagram: OpenShift security best practices.

The different container attack vectors 

These changes have considerable consequences for security and how you approach your OpenShift security best practices. The security principles still apply, and we still are concerned with reducing the blast radius, least privileges, etc. Still, they must be used from a different perspective and to multiple new components in a layered approach. Security is never done in isolation.

So, as the number of entry points to the system increases, the attack surface broadens, leading us to several docker container security attack vectors not seen with the monolithic. We have, for example, attacks on the Host, images, supply chain, and container runtime. There is also a considerable increase in the rate of change for these types of environments; an old joke says that a secure application is an application stack with no changes.

So when you change, you can open the door to a bad actor. Today’s application varies considerably a few times daily for an agile stack. We have unit and security tests and other safety tests that can reduce mistakes, but no matter how much preparation you do, there is a chance of a breach whenever there is a change.

So, we have environmental changes that affect security and some alarming technical challenges to how containers run as default, such as running as root by default and with an alarming amount of capabilities and privileges. The following image displays attack vectors that are linked explicitly to containers.

container attack vectors
Diagram: Container attack vectors. Source Adriancitu

Challenges with Securing Containers

  • Containers running as root

So, as you know, containers run as root by default and share the Kernel of the Host OS, and the container process is visible from the Host. This in itself is a considerable security risk when a container compromise occurs. When a security vulnerability in the container runtime arose, and a container escape was performed, as the application ran as root, it could become root on the underlying Host.

Therefore, if a bad actor gets access to the Host and has the correct privileges, it can compromise all the hosts’ containers.

Video: Docker Container Security 

In this video, we will go through some basics of containers. The building blocks of containers are namespaces and control groups. However, they share the host kernel, which is a security concern. We will also address container orchestrators with Kubernetes and discuss PODs, Services, NAT, and VXLAN.

Highlighting Docker Containers
Prev 1 of 1 Next
Prev 1 of 1 Next

Risky Configuration

Containers often run with excessive privileges and capabilities—much more than they need to do their job efficiently. As a result, we need to consider what privileges the container has and whether it runs with any unnecessary capabilities it does not need.

Some of the capabilities a container may have are defaults that fall under risky configurations and should be avoided. You want to keep an eye on the CAP_SYS_ADMIN. This flag grants access to an extensive range of privileged activities.

The container has isolation boundaries by default with namespace and control groups ( when configured correctly). However, granting the excessive container capabilities will weaken the isolation between the container and this Host and other containers on the same Host. They are, essentially, removing or dissolving the container’s ring-fence capabilities.

Starting OpenShift Security Best Practices

Then, we have security with OpenShift that overcomes many of the default security risks you have with running containers. And OpenShift does much of this out of the box. If you want further information on securing an OpenShift cluster, kindly check out my course for Pluralsight on OpenShift Security and OpenShift Network Security.

OpenShift Container Platform (formerly known as OpenShift Enterprise) or OCP is Red Hat’s offering for the on-premises private platform (PaaS). OpenShift is based on the Origin open-source project and is a Kubernetes distribution.

The foundation of the OpenShift Container Platform and OpenShift Network Security is based on Kubernetes and, therefore, shares some of the same networking technology and some enhancements. However, as you know, Kubernetes is a complex beast and can be utilized by itself when trying to secure clusters.  OpenShift does an excellent job of wrapping Kubernetes in a layer of security, such as using Security Context Constraints (SCCs) that give your cluster a good security base.

Security Context Constraints

By default, OpenShift prevents the cluster container from accessing protected functions. These functions — Linux features such as shared file systems, root access, and some core capabilities such as the KILL command — can affect other containers running in the same Linux kernel, so the cluster limits access.

Most cloud-native applications work fine with these limitations, but some (especially stateful workloads) need greater access. Applications that need these functions can still use them but need the cluster’s permission.

The application’s security context specifies the permissions that the application needs, while the cluster’s security context constraints specify the permissions that the cluster allows. An SC with an SCC enables an application to request access while limiting the access that the cluster will grant.

What are security contexts and security context constraints?

A pod configures a container’s access with permissions requested in the pod’s security context and approved by the cluster’s security context constraints:

A security context (SC), defined in a pod, enables a deployer to specify a container’s permissions to access protected functions. When the pod creates the container, it configures it to allow these permissions and block all others. The cluster will only deploy the pod if the permissions it requests are permitted by a corresponding SCC.

A security context constraint (SCC), defined in a cluster, enables an administrator to control permissions for pods, permissions that manage containers’ access to protected Linux functions. Similarly to how role-based access control (RBAC) manages users’ access to a cluster’s resources, an SCC manages pods’ access to Linux functions.

By default, a pod is assigned an SCC named restricted that blocks access to protected functions in OpenShift v4.10 or earlier. Instead, in OpenShift v4.11 and later, the restricted-v2 SCC is used by default. For an application to access protected functions, the cluster must make an SCC that allows it to be available to the pod.

While an SCC grants access to protected functions, each pod needing access must request it. To request access to the functions its application needs, a pod specifies those permissions in the security context field of the pod manifest. The manifest also specifies the service account that should be able to grant this access.

When the manifest is deployed, the cluster associates the pod with the service account associated with the SCC. For the cluster to deploy the pod, the SCC must grant the permissions that the pod requests.

One way to envision this relationship is to think of the SCC as a lock that protects Linux functions, while the manifest is the key. The pod is allowed to deploy only if the key fits.

Security Context Constraints
Diagram: Security Context Constraints. Source is IBM

A final note: Security context constraint

When your application is deployed to OpenShift in a virtual data center design, the default security model will enforce that it is run using an assigned Unix user ID unique to the project for which you are deploying it. Now, we can prevent images from being run as the Unix root user. When hosting an application using OpenShift, the user ID that a container runs as will be assigned based on which project it is running in.

Containers cannot run as the root user by default—a big win for security. SCC also allows you to set different restrictions and security configurations for PODs.

So, instead of allowing your image to run as the root, which is a considerable security risk, you should run as an arbitrary user by specifying an unprivileged USER, setting the appropriate permissions on files and directories, and configuring your application to listen on unprivileged ports.

OpenShift Security Context Constraints
Diagram: OpenShift security context constraints.

OpenShift Network Security: SCC defaults access

Security context constraints let you drop privileges by default, which is essential and still the best practice. Red Hat OpenShift security context constraints (SCCs) ensure that, by default, no privileged containers run on OpenShift worker nodes—another big win for security. Access to the host network and host process IDs are denied by default. Users with the required permissions can adjust the default SCC policies to be more permissive.

So, when considering SCC, think of SCC admission controllers as restricting POD access, similar to how RBAC restricts user access. To control the behavior of pods, we have security context constraints (SCCs). These cluster-level resources define what resources pods can access and provide additional control. 

Security context constraints let you drop privileges by default, a critical best practice. With Red Hat OpenShift SCCs, no privileged containers run on OpenShift worker nodes. Access to the host network and host process IDs are denied by default—a big win for OpenShift security.

Video: OpenShift Networking

The application stack previously had very few components, maybe just a cache, web server, and database. The most common network service allows a source to reach an application endpoint or load balance to several endpoints using a load-balancing algorithm. The sole purpose of the network was to provide endpoint reachability.

Changes inside the data center drive networks and network services toward becoming more integrated with the application. Nowadays, the network function exists no longer solely to satisfy endpoint reachability; it is fully integrated, and in the case of Red Hat’s Openshift, the network is represented as a Software-Defined Networking (SDN) layer.

OpenShift Networking Explained
Prev 1 of 1 Next
Prev 1 of 1 Next

Restricted security context constraints (SCCs)

A few SCCs are available by default, and you may have the head of the restricted SCC. By default, all pods, except those for builds and deployments, use a default service account assigned by the restricted SCC, which doesn’t allow privileged containers – that is, those running under the root user and listening on privileged ports are ports under <1024. SCC can be used to manage the following:

    1. Privilege Mode: this setting allows or denies a container running in privilege mode. As you know, privilege mode bypass any restriction such as control groups, Linux capabilities, secure computing profiles, 
    2. Privilege Escalation: This setting enables or disables privilege escalation inside the container ( all privilege escalation flags)
    3. Linux Capabilities: This setting allows the addition or removal of specific Linux capabilities
    4. Seccomp profile – this setting shows which secure computing profiles are used in a pod.
    5. Root-only file system: this makes the root file system read-only 

The goal is to assign the fewest possible capabilities for a pod to function fully. This least-privileged model ensures that pods can’t perform tasks on the system that aren’t related to their application’s proper function. The default value for the privileged option is False; setting the privileged option to True is the same as giving the pod the capabilities of the root user on the system. Although doing so shouldn’t be common practice, privileged pods can be helpful under certain circumstances. 

OpenShift Network Security: Authentication

The term authentication refers to the process of validating one’s identity. Usually, users aren’t created in OpenShift but are provided by an external entity, such as the LDAP server or GitHub. The only part where OpenShift steps in is authorization—determining roles and permissions for a user.

OpenShift supports integration with various identity management solutions in corporate environments, such as FreeIPA/Identity Management, Active Directory, GitHub, Gitlab, OpenStack Keystone, and OpenID.

OpenShift Network Security: Users and identities

A user is any human actor who can request the OpenShift API to access resources and perform actions. Users are typically created in an external identity provider, usually a corporate identity management solution such as Lightweight Directory Access Protocol (LDAP) or Active Directory.

To support multiple identity providers, OpenShift relies on the concept of identities as a bridge between users and identity providers. A new user and identity are created upon the first login by default. There are four ways to map users to identities:

Service accounts

Service accounts allow us to control API access without sharing users’ credentials. Pods and other non-human actors use them to perform various actions and are a central vehicle by which their access to resources is managed. By default, three service accounts are created in each project:

Authorization and role-based access control

Authorization in OpenShift is built around the following concepts:

Rules: Sets of actions allowed to be performed on specific resources.
Roles: Collections of rules that allow them to be applied to a user according to a specific user profile. Roles can be used either at the cluster or project level.
Role bindings: Associations between users/groups and roles. A given user or group can be associated with multiple roles.

If pre-defined roles aren’t sufficient, you can always create custom roles with just the specific rules you need.

 

Summary: OpenShift Security

In the ever-evolving technological landscape, ensuring the security of your applications is of utmost importance. OpenShift, a powerful containerization platform, offers robust security features to protect your applications and data. This blog post explored some essential OpenShift security best practices to help you fortify your applications and safeguard sensitive information.

Section 1: Understand OpenShift Security Model

OpenShift follows a layered security model that provides multiple levels of protection. It is crucial to understand this model to implement adequate security measures. From authentication and authorization mechanisms to network policies and secure container configurations, OpenShift offers a comprehensive security framework.

Section 2: Implement Strong Authentication Mechanisms

Authentication is the first line of defense against unauthorized access. OpenShift supports various authentication methods, including username/password, token-based, and integration with external authentication providers like LDAP or Active Directory. Implementing robust authentication mechanisms ensures that only trusted users can access your applications and resources.

Section 3: Apply Fine-Grained Authorization Policies

Authorization plays a vital role in controlling users’ actions within the OpenShift environment. You can limit privileges to specific users or groups by defining fine-grained access control policies. OpenShift’s Role-Based Access Control (RBAC) allows you to assign roles with different levels of permissions, ensuring that each user has appropriate access rights.

Section 4: Secure Container Configurations

Containers are at the heart of OpenShift deployments; securing them is crucial for protecting your applications. Employing best practices such as using trusted container images, regularly updating base images, and restricting container capabilities can significantly reduce the risk of vulnerabilities. OpenShift’s security context constraints enable you to define and enforce security policies for containers, ensuring they run with the minimum required privileges.

Section 5: Enforce Network Policies

OpenShift provides network policies that enable you to define traffic flow rules between your application’s different components. By implementing network policies, you can control inbound and outbound traffic, restrict access to specific ports or IP ranges, and isolate sensitive components. This helps prevent unauthorized communication and protects your applications from potential attacks.

Conclusion:

Securing your applications on OpenShift requires a multi-faceted approach, encompassing various layers of protection. By understanding the OpenShift security model, implementing strong authentication and authorization mechanisms, securing container configurations, and enforcing network policies, you can enhance the overall security posture of your applications. Stay vigilant, keep up with the latest security updates, and regularly assess your security measures to mitigate potential risks effectively.