What is Security Context? Misconfigurations & Best Practices

IT resources are very much like company employees: each one has different roles and responsibilities – and by extension, each one should have different rights and privileges from a security standpoint. You typically wouldn’t want an employee from the marketing department to be able to access all of the finance department’s files, for example. In a company, guaranteeing that people don’t step outside of their lane is tough, and requires a strong culture of governance.

But in IT, you can automatically enforce strong security standards through security context. In applications, operating systems, container orchestration platforms, and beyond, security context makes it possible to define clear, granular access rights for each resource, helping to mitigate security risks.

That, at least, is the short version of what security contexts do. For the details, read on as we explain what security context means and how to manage it across a variety of modern IT systems.

What is security context, and why does it matter?

Security context is the set of rules that define which access rights and privileges an IT resource should have when it runs. For instance, in Kubernetes, security context could define which user and group a container will run as, whether the container can run in privileged mode and whether the container’s file system should be read-only.

Most systems don’t require admins to define security context; you can run resources without it. However, doing so can lead to major security risks because security context places limits on what a workload can do and how it interacts with other resources.

You can think of security context as akin to giving different keys to different people inside an office building. The keys that each person receives reflect his or her role and the rooms that he or she needs to access. If there were no security context in place, everyone would be able to walk into any room in the building, which would not be very secure. But with security context, each person receives the access privileges necessary to perform a given job, and no more.

For clarity’s sake, it’s worth noting that security context as we’re discussing it here is a concept, not a specific tool. That said, it’s also the name of specific features in certain systems – most notably Kubernetes, which has a built-in Security Context capability. But you can establish security context in other systems, too, even if the tools you’d use for doing so are not explicitly named security context. Any type of tool or framework that can automatically enforce predefined access controls and privileges can function as a security context solution.

For the record, security context should not be confused with secure context, which is a concept in Web development that provides encrypted communication channels. Secure contexts are an important part of Web application security, but they’re distinct from the concept of security context.

How security context works in modern infrastructure

The process for implementing and enforcing security context varies between systems. For example, Linux uses add-on security modules, like SELinux, to define and enforce security context, whereas Kubernetes has built-in security context functionality that can govern Pods and containers.

At a high level, however, security context works in the same basic way across all types of modern infrastructure. The process is usually as follows:

• Admins configure rules that define the security context for each resource. A resource could be a process, an application, an infrastructure component such as a container, a cloud service, or virtually any other object that could exist within an IT system.
• A controller continuously monitors resources and their requests and automatically blocks requests that fall outside the scope of each resource’s security context. For example, if a container has a specific user ID defined in its security context, but it tries to change its user ID to something different at runtime, the change would be blocked.

In this way, security context offers an automated, scalable solution for managing access rights for resources. Admins can simply specify what should happen from a security standpoint by defining a security context, then rely on automated tools to enforce the context.

Types of security contexts

As we’ve mentioned, security contexts can apply to different types of systems. Here’s a look at some common examples.

Application-level security context

For individual applications, security context can define which external resources (such as files or databases) an application can access. It can also enforce rules related to the user and group IDs that the process uses when it executes.

Operating system security context

At the operating system level, security context can govern how applications and processes manage resources across the entire system. For instance, security context could prevent one user from accessing resources owned by a different user on the same system, or to ensure that multiple processes can’t access each other’s memory.

Kubernetes security context

In Kubernetes, security context is a specific feature that can control security settings for Pods and containers. It does this in part by allowing admins to enable or disable privileged mode, as well as to set user and group IDs. It also integrates with Linux-based security modules, including SELinux and AppArmor, to enable additional security controls that are enforced via these modules (as opposed to by Kubernetes itself).

Identity and Access Management contexts

Most modern cloud environments offer Identity and Access Management (IAM) frameworks that allow admins to define the privileges available for managing cloud resources. For instance, an IAM policy could allow a user to start and stop a virtual server instance, but not delete it.

Elements of security context

To work well, security context and the tooling that powers it must be able to support the following core elements:

• A clear definition of which rights and privileges a resource should have.
• A way of identifying and authenticating resources, such that the system can accurately associate resources with the appropriate security context.
• A means of monitoring the resource’s requests to determine what the resource is actually doing.
• An enforcement mechanism that blocks events that violate the security context.

Other, optional features may add to the functionality of security context. For example, auditing capabilities, which report the requests made by resources, can help to validate that security contexts were properly enforced.

Security context in zero trust environments

Security context can apply to any type of environment, but it’s especially valuable when implementing so-called zero trust.

Zero trust means that an environment or network never trusts resources, or grants them access to other resources, by default. Instead, each resource must undergo a validation process before it receives any access rights.

Security context helps to enable zero trust by defining which access rights a resource should receive once it passes the validation tests. Without security context, a validated resource would have unlimited privileges. But zero trust makes it possible to enforce a policy of least privilege (which means that each resource receives only the minimum privileges necessary to perform its role), which in turn enhances the value that zero trust enables.

Common security context misconfigurations

While security context is a powerful way to mitigate risks, it’s only as effective as the configuration that powers it. If you misconfigure security context policies, they become ineffective.

That’s why it’s important to steer clear of common security context misconfigurations, such as the following:

• Running containers as root: Failing to set a non-root user allows processes inside the container to run with full system privileges. This can increase the harm resulting from a compromise because a breached container would have more access rights when it runs as root.
• Allowing privilege escalation: Leaving allowPrivilegeEscalation set to true allows processes to gain higher privileges than intended, even if they start out with restricted privileges.
• Mounting sensitive host paths: Misconfigurations that mount host directories like /var/run/docker.sock or /etc inside containers may expose critical host-level files and control sockets. In turn, if the container is breached, attackers can use these paths to compromise host-level resources.
• Omitting read-only filesystem settings: Forgetting to set readOnlyRootFilesystem to true may allow attackers or buggy applications to modify system files inside a container.

The tricky thing about security context misconfigurations like these is that security context tools won’t point them out to you. Nor will they alert you to gaps or oversights (like forgetting to specify whether a filesystem should be read-only). The tools simply enforce whichever contexts you set; it’s up to you to make sure the contexts properly address all potential risks.

Best practices for managing security contexts

To use security contexts to maximum effect, consider these best practices:

• Start with templates: Instead of developing each security context from scratch, use templates that include a default set of rules and values. Templates help prevent you from overlooking aspects of a security context that you may not have thought of.
• Enforce least privilege: As noted above, it’s a best practice to grant each resource the minimum level of privileges it needs to perform its role. Excess privileges create unnecessary risk.
• Deploy strong authentication controls: Since security context only works when resources are properly authenticated, be sure that your authentication controls are robust. For example, for human users, requiring multi-factor authentication can reduce the risk that attackers will be able to impersonate a legitimate user as a way of bypassing security context restrictions.
• Revoke outdated or unused contexts: Rather than letting security contexts sit around forever, remove those that you’re no longer using. This helps ensure that you don’t grant a resource privileges that it should no longer have. It also mitigates the risk of applying multiple, conflicting security contexts to the same resource, which can happen if you have an old policy still in place and you also define a new one.

Emerging trends shaping security context

As of 2025, the most notable trend impacting security context is the use of AI to help automate both the generation and management security contexts.

Historically, admins had to write security contexts by hand in most cases – an unavoidable task because each resource’s needs are different, and only humans could define suitable security policies. But increasingly, AI can also assess the roles and responsibilities of each resource, then write security rules accordingly. Humans may still need to review the policies, but even so, using AI to generate drafts saves a lot of time.

Going further, AI also has the potential to modify security contexts automatically in real time – a process that would be tough for humans to do well at scale. This is especially useful in environments where the access needs of resources change constantly. For example, imagine a container that needs to write to a database temporarily as part of a batch processing operation, but no longer needs the database access after the batch of data is processed. Using AI-powered automations, the database access privileges could be revoked as needed, helping to strengthen overall security.

Zero trust and least privilege also remain important trends related to security context. These concepts have been popular in cybersecurity circles for about a decade, so they’re no longer groundbreaking ideas, but many organizations remain in the process of implementing them fully.

How groundcover strengthens security context through unified observability

Security context is one step toward maintaining a strong security posture. But to detect and respond to security risks, you also need deep context – which is where observability solutions like groundcover come in.

With groundcover, you can quickly determine the health and status of every application, process, node, and so on that you’re managing. Used alongside security context rules, these observability insights add critical context for understanding if, for example, a container’s attempt to access a resource is part of a normal pattern, or an anomaly that could reflect efforts to bypass security controls.

What’s more, because groundcover uses eBPF to collect observability data hyper-efficiently, it delivers the context and insights you need to manage risks without adding substantial overhead to your systems or degrading performance.

Context is everything, especially in security

Having the ability to restrict what IT resources can do – which is what security context enables – is a first step toward mitigating risks. But you also need context showing you what your resources are actually doing. This is the only way to determine whether security contexts are being enforced properly, and to detect gaps that you may not have thought of when defining contexts.

FAQ

How does security context improve incident investigation and response?

Security context can help to improve incident investigation and response by clearly defining the access rights that a given resource was supposed to have. Teams can compare this to the actions the resource actually took to determine whether a security incident took place.

What role does observability play in maintaining security context?

While observability and security context are distinct concepts, they complement each other because observability data (meaning data about the internal state of a system) reveals what’s actually happening inside a system. Using this insight, you can determine whether security contexts are being appropriately enforced.

How does groundcover help teams achieve real-time security context across cloud-native environments?

As an observability solution that delivers continuous, real-time visibility into what’s happening across complex, distributed environments (like Kubernetes), groundcover provides the insight necessary to assess the health and status of resources. This visibility adds crucial context to security policy enforcement. Thus, while groundcover is an observability solution rather than a security tool, it helps to supercharge the effectiveness of security operations by providing additional context that security tools don’t typically generate on their own.