Crossplane Usages
Crossplane usages let you define clear links between two managed cloud resources. You set them up to stop one resource from deleting before another finishes its work. Platform teams use this feature to build safe cloud setups inside Kubernetes. Without these rules, Kubernetes deletes resources all at once. Broad roles also let engineers delete shared networks while databases still run inside them. This causes stuck deletions and broken cloud accounts. How crossplane usages work in your cluster
Crossplane Composition Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Crossplane usages let you define clear links between two managed cloud resources. You set them up to stop one resource from deleting before another finishes its work. Platform teams use this feature to build safe cloud setups inside Kubernetes. Without these rules, Kubernetes deletes resources all at once. Broad roles also let engineers delete shared networks while databases still run inside them. This causes stuck deletions and broken cloud accounts.
How crossplane usages work in your cluster
In a standard setup, Crossplane talks to cloud APIs through Kubernetes controllers. When a team creates a database and a network, both exist as separate objects. Kubernetes does not know that the database needs the network to stay alive. If an engineer deletes the whole group, the cloud API gets both delete requests together. The network tries to shut down while the database still holds an active IP address. The cloud provider rejects the network deletion, and the cluster state gets stuck.
To fix this, you create a usage object in your cluster. This object names two specific items: the resource being used and the resource using it. When the usage object is active, Crossplane adds a protective lock to the underlying resource. If someone tries to delete that underlying resource, the controller blocks the request. It waits until the dependent resource is gone first. Once the dependent item finishes deleting, the controller removes the usage object and deletes the base resource.
You can also use a usage object without naming a second resource. Instead, you write a plain text reason explaining why the resource must stay. This acts like a simple lock against accidental deletion by operators or automated scripts. Teams use this lock to protect production databases or shared cluster tools during updates.
What native dependency rules solve and what they miss
Native dependency rules solve the problem of out-of-order teardown in cloud setups. They make sure that cluster operators and Helm charts can uninstall before cloud networks vanish. For example, an monitoring agent inside a cluster needs cloud permissions to clean up its own load balancers. A usage rule keeps the permission role alive until the agent finishes its cleanup job. This keeps your cloud bill clean and stops orphaned disks or IP addresses from piling up.
Crossplane Composition Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Still, these cluster rules only control the life cycle of the resource definitions. They do not watch or control how engineers interact with the live systems day to day. Kubernetes roles and usage locks decide who can edit manifests or delete objects. They do not check what individual SQL queries or shell commands do inside a running database or cluster.
An engineer with cluster edit rights can still read secret keys stored in the namespace. With those keys, they can log in directly to the database and run a destructive drop command. The usage lock keeps the cloud database instance running, but the data inside it is gone. Native cluster tools also do not rewrite sensitive data like emails or card numbers in query results. To protect the actual data and commands in flight, teams need controls at the session level.
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
What happens when you try to delete a protected resource?
Crossplane intercepts the delete request and keeps the resource in a waiting state. It logs a message showing which dependent resource or rule blocks the deletion. Once you remove the dependent resource, the deletion finishes on its own.
Can crossplane usages protect cluster apps like Helm releases?
Yes, a usage object can link a cloud resource to any Kubernetes resource type. You can block a cloud cluster or permission role from deleting until a Helm release is gone. This ensures internal cluster apps clean up their cloud load balancers first.
Do usage rules stop users from dropping tables inside a database?
No, usage rules only work on the Kubernetes API level to block resource teardown. They do not inspect database traffic or stop a user with a password from dropping tables. You need runtime command controls and query masking to protect data inside the database.