Ocp API
You use the ocp api by sending REST requests to your OpenShift control plane. Each request needs a valid bearer token and a role that allows the action. Many teams start by giving broad cluster roles to get their apps running fast. Over time, those wide roles let users or scripts change live workloads by mistake. How the ocp api works in your cluster The control plane runs an endpoint that takes HTTP requests from users and tools. Every command you run in the client tool sends a call to this
API Key Management: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You use the ocp api by sending REST requests to your OpenShift control plane. Each request needs a valid bearer token and a role that allows the action. Many teams start by giving broad cluster roles to get their apps running fast. Over time, those wide roles let users or scripts change live workloads by mistake.
How the ocp api works in your cluster
The control plane runs an endpoint that takes HTTP requests from users and tools. Every command you run in the client tool sends a call to this endpoint. When you create a pod or update a route, you send data there. The server reads the payload and writes the new state to the cluster store.
First, a user or service account must log in to get a token. The built-in OAuth server checks the user identity against your team directory. Once the server confirms the user, it hands back a signed bearer token. The client puts this token in the header of every single request.
Next, the control plane checks role-based rules to see what the token can do. Roles list the exact objects and verbs a user can read or write. A role binding links that role to a user, group, or service account. You can scope these rules to one project or across the whole cluster.
What native ocp api roles solve and what they miss
Native cluster roles are great for grouping users by their daily job tasks. You can let developers read pod logs in a test project with ease. At the same time, you can block them from deleting production storage volumes. Service accounts also help automated build tools deploy new code on a schedule.
Still, static roles only decide who can log in and reach an endpoint. They do not inspect the exact payload or command inside a valid session. If an engineer has edit rights, they can still run a bad update. A script with a leaked token can also read secrets across that namespace.
API Key Management: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Long-lived service account tokens create another big risk for platform teams. Teams often copy these tokens into external build tools and forget about them. If someone steals that token, they get full project rights right away. Native cluster logs show the service account name, not the human who triggered it.
Steps to tighten cluster request rules
Start by auditing all cluster role bindings that grant wide admin rights. Remove human users from permanent admin groups and use project-scoped roles instead. Give each app its own service account with only the verbs it needs. Never share one service account token across multiple build pipelines or teams.
Set short time limits on user tokens so old sessions expire on their own. Turn on cluster audit logs to record every request body and response code. Review these logs each week to spot failed login tries or odd changes. When a user only needs a quick fix, grant temporary rights per request.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
How do I get a token for the ocp api?
You log in through the cluster OAuth server using your team identity credentials. The server returns a bearer token that you include in your request headers.
What is the difference between a role and a cluster role?
A standard role applies only to resources inside one specific project namespace. A cluster role applies across all projects and covers cluster-wide objects like nodes.
How can teams reduce the risk of leaked service account tokens?
Bind each service account to the smallest possible set of resource verbs. Rotate tokens often and use short-lived tokens instead of static secrets when possible.