OpenShift Projects and Namespaces

Learn how OpenShift Projects and Kubernetes Namespaces organize applications, isolate resources, and enable secure multi-team deployments with real-world enterprise examples.

Introduction

As organizations adopt microservices and cloud-native architectures, hundreds or even thousands of applications run inside the same OpenShift cluster. Without proper organization, managing these applications would quickly become difficult.

OpenShift solves this problem using Projects, while Kubernetes provides the underlying concept called Namespaces.

A Project or Namespace acts as a logical boundary that groups related resources such as Pods, Deployments, Services, ConfigMaps, and Secrets.

In this article, you'll learn why Projects and Namespaces are essential for enterprise applications and how they help organize, secure, and isolate workloads.

Learning Objectives

By the end of this article, you will understand:

What is a Namespace?
What is an OpenShift Project?
Project vs Namespace
Why enterprises use Projects
Resource isolation
Security boundaries
Environment separation
Real-world architecture
Best practices

Why Do We Need Projects?

Imagine an OpenShift cluster hosting applications for multiple teams.

Without Projects:

Resources become difficult to manage.
Applications interfere with each other.
Security becomes complicated.
Teams may accidentally modify another team's resources.

Projects solve these problems by creating logical boundaries.

Without Projects

flowchart LR
    CLUSTER["OpenShift Cluster"]

    CLUSTER --> PAYMENT["Payment Pods"]
    CLUSTER --> ORDER["Order Pods"]
    CLUSTER --> INVENTORY["Inventory Pods"]
    CLUSTER --> CUSTOMER["Customer Pods"]
    CLUSTER --> NOTIFY["Notification Pods"]

Everything exists together without organization.

With Projects

flowchart TD
    CLUSTER["OpenShift Cluster"]

    PROJECT1["Payments Project"]
    PROJECT2["Orders Project"]
    PROJECT3["Inventory Project"]

    PAYMENT["Payment Pods"]
    ORDER["Order Pods"]
    INVENTORY["Inventory Pods"]

    CLUSTER --> PROJECT1
    CLUSTER --> PROJECT2
    CLUSTER --> PROJECT3

    PROJECT1 --> PAYMENT
    PROJECT2 --> ORDER
    PROJECT3 --> INVENTORY

Each application is isolated.

What is a Kubernetes Namespace?

A Namespace is a logical partition inside a Kubernetes cluster.

Namespaces allow multiple teams and applications to share the same cluster safely.

Each Namespace contains its own:

Pods
Services
Deployments
Secrets
ConfigMaps
Persistent Volumes
Jobs

Namespaces do not create a new cluster; they organize resources within the existing cluster.

What is an OpenShift Project?

An OpenShift Project is essentially a Kubernetes Namespace with additional OpenShift features.

A Project includes:

Namespace
RBAC
Quotas
Security Policies
Network Policies
Developer Permissions

Think of it as:

OpenShift Project
      =
Kubernetes Namespace
      +
Enterprise Features

Project Architecture

flowchart TD
    CLUSTER["OpenShift Cluster"]

    subgraph ENVIRONMENTS["Projects / Namespaces"]
        DEV["Development"]
        QA["QA"]
        UAT["UAT"]
        PROD["Production"]
    end

    CLUSTER --> DEV
    CLUSTER --> QA
    CLUSTER --> UAT
    CLUSTER --> PROD

Each environment has its own isolated Project.

Typical Enterprise Structure

flowchart TD

Company

--> Banking

--> Insurance

--> Payments

Banking --> Dev

Banking --> QA

Banking --> Prod

Insurance --> Dev2

Insurance --> QA2

Insurance --> Prod2

Each business domain maintains separate Projects for every environment.

Resources Inside a Project

flowchart TD

Project

--> Deployment

Project

--> Pods

Project

--> Service

Project

--> Route

Project

--> ConfigMap

Project

--> Secret

All application resources belong to a Project.

Real-World Banking Example

A banking organization may have several applications.

Payments

Accounts

Loans

Cards

Customer Profile

Notifications

Instead of deploying everything into one Namespace, each application gets its own Project.

flowchart TD
    subgraph CLUSTER["OpenShift Cluster"]
        subgraph PAY["Payments Project"]
            PAY_POD["Payment Pods"]
        end

        subgraph ACC["Accounts Project"]
            ACC_POD["Account Pods"]
        end

        subgraph LOAN["Loans Project"]
            LOAN_POD["Loan Pods"]
        end

        subgraph CARD["Cards Project"]
            CARD_POD["Card Pods"]
        end
    end

This keeps applications isolated and easier to manage.

Environment Isolation

Almost every enterprise uses separate environments.

flowchart LR

Developer

--> Dev

Dev --> QA

QA --> UAT

UAT --> Production

Each environment usually maps to a different OpenShift Project.

Example:

payment-dev

payment-qa

payment-uat

payment-prod

Why Environment Separation Matters

Suppose a developer deploys a buggy version.

If Dev and Production share the same Project, production users could be affected.

Separate Projects prevent this issue.

Multi-Team Collaboration

flowchart TD
    PLATFORM["Platform Team"]

    subgraph OCP["OpenShift Cluster"]
        TEAMA["Team A Project"]
        TEAMB["Team B Project"]
        TEAMC["Team C Project"]
    end

    PLATFORM --> OCP

Each team only accesses its own Project.

Resource Isolation

Projects isolate resources such as:

CPU
Memory
Storage
Secrets
ConfigMaps

One team's application cannot accidentally consume another team's resources.

Security Isolation

Projects also isolate security.

Example:

Project A

Database Password
API Keys
Certificates

Project B

Different Secrets
Different Users
Different Permissions

Secrets are never shared automatically.

RBAC Example

flowchart TD
    subgraph USERS["Users"]
        DEV["Developer"]
        QA["QA Engineer"]
        ADMIN["Admin"]
    end

    subgraph PROJECTS["OpenShift Projects"]
        PAY["Payment Project"]
        QA_NS["QA Project"]
        ALL["All Projects"]
    end

    DEV --> PAY
    QA --> QA_NS
    ADMIN --> ALL

Different users receive different access levels.

Naming Convention

Most organizations follow a consistent naming convention.

payment-dev

payment-test

payment-uat

payment-prod

banking-dev

banking-prod

insurance-dev

insurance-prod

This makes Projects easy to identify.

Creating a Project

Using the OpenShift CLI:

oc new-project payment-dev

List Projects:

oc projects

Switch Project:

oc project payment-dev

Delete Project:

oc delete project payment-dev

Verify Current Project

oc project

Example output:

Using project "payment-dev"

Always verify the active Project before deploying.

Best Practices

One application per Project whenever possible.
Separate environments.
Use meaningful names.
Apply Resource Quotas.
Configure RBAC.
Store Secrets inside the Project.
Use Network Policies.
Avoid deploying unrelated applications together.

Common Mistakes

❌ Using the default Project for all applications.

❌ Sharing Secrets across unrelated applications.

❌ Deploying Development and Production in the same Project.

❌ Giving all developers cluster-admin access.

❌ Ignoring Resource Quotas.

Kubernetes Namespace vs OpenShift Project

Kubernetes Namespace	OpenShift Project
Logical grouping	Logical grouping
Resource isolation	Resource isolation
Basic RBAC	Enhanced RBAC
Manual setup	Simplified management
Community platform	Enterprise platform

A Project is essentially an enhanced Namespace with enterprise capabilities.

Advantages

Better organization
Environment isolation
Team isolation
Improved security
Easier deployments
Simplified administration
Better resource management

Real-Time Enterprise Scenario

A financial company has:

25 development teams
300 microservices
4 environments

Instead of running everything together, they organize workloads like this:

payments-dev
payments-qa
payments-prod

accounts-dev
accounts-qa
accounts-prod

cards-dev
cards-qa
cards-prod

This allows independent deployments while maintaining security and operational boundaries.

Summary

Projects and Namespaces are fundamental building blocks of OpenShift.

Key takeaways:

A Namespace is a logical partition within a Kubernetes cluster.
An OpenShift Project is a Namespace enhanced with enterprise features.
Projects isolate applications, teams, environments, and resources.
They improve security, simplify deployments, and enable multi-team collaboration.
Every enterprise OpenShift deployment relies heavily on well-designed Project structures.

Interview Questions

What is a Kubernetes Namespace?
What is an OpenShift Project?
What is the difference between a Project and a Namespace?
Why do enterprises use Projects?
Can multiple applications share the same Project?
What resources belong to a Project?
How does RBAC work with Projects?
Why separate Dev and Production Projects?
What is the command to create a Project?
What are the best practices for naming Projects?

Loading likes...

Comments

Share a question, correction, or practical insight about this article.

Loading approved comments...