[EN] Acdc Das Geheimnis Hinter Robusten Berechtigungsmodellen

Julian | Aug 15, 2025 min read
[EN] Acdc Das Geheimnis Hinter Robusten Berechtigungsmodellen

Hello everyone,

When it comes to permissions in our applications, most of us first think of roles (Admin, User) or ACLs (Access Control Lists). This works, but with complex systems it quickly becomes confusing. This is where ACDC comes into play, a mental model that helps us make permissions logic cleaner and more scalable.

ACDC stands for:

  • Attribute
  • Context
  • Definition
  • Constraints

ACDC is not a new framework, but a systematic approach to designing permissions. It’s a mental checklist that forces us to think about all aspects of a permission request.

Attributes: Who or what?

The Attributes are the basic properties of everything involved in a permission request. These are the subjects, objects and actions.

  • Subject Attributes: Who is the user? What are its properties?
    • UserID, Role, Department, Location
  • Object Attributes: What is being accessed?
    • Document ID, Document Type, Owner, Status
  • Action Attributes: What should be done?
    • read, write, delete, approve

By clearly defining these attributes, we create the building blocks for our authorization rules.

Context: Where, when, how?

The Context describes the circumstances of the request. It provides dynamic information that goes beyond static attributes and can influence authorization.

  • Time: Is access only allowed during working hours?
  • Location/Network: Does the request come from the company network or externally?
  • Device: Is a mobile device or desktop used?
  • Request data: What additional information is included in the request?

Context is critical to making permissions adaptive.

Definition: The rule itself

The definition is the actual permission rule we establish. It combines attributes and context to formulate a clear instruction. The definition is typically written in natural language before we put it into code.

Example of definition:

“A user with the role ‘Employee’ is allowed to read a document of type ‘Report’ if they are part of the same department in which the document was created.”

This definition is precise and easy to understand. It forms the basis for our code.

Constraints: Exceptions and restrictions

The Constraints are the fine-grained restrictions or conditions that must be met for the rule to apply. They are often Boolean expressions.

Example of constraints:

  • User.Department == Document.Department
  • Document.status == 'published'
  • Request.time >= 08:00 && Request.time <= 17:00

Constraints make the rules powerful and expressive without making them unnecessarily complex.

ACDC in practice

Let’s imagine we implement the above rule in our code:

public boolean darfLesen(Benutzer benutzer, Dokument dokument) {
    // 1. Definition (wer, was, was)
    if (!benutzer.hatRolle("Mitarbeiter")) {
        return false;
    }
    if (!dokument.getTyp().equals("Bericht")) {
        return false;
    }

    // 2. Constraints (Bedingungen)
    if (!benutzer.getAbteilung().equals(dokument.getAbteilung())) {
        return false;
    }

    // 3. Wenn alle Constraints erfuellt sind, ist die Berechtigung erteilt
    return true;
}

The if statements serve as our constraints. But imagine if we also had the context that access is only allowed from a specific network. Then we would just add another constraint.

Conclusion

The ACDC model helps us look beyond simple roles and ACLs and design truly adaptive, understandable permission models. By thinking systematically about Attributes, Context, Definition and Constraints, we create a solid foundation for our security architecture that grows with our systems and doesn’t get lost in a tangled mess of if-else blocks.

How do you design your authorization models? Do you use a similar approach?

But that wasn’t all! The ACDC model can be easily transferred to working with Kubernetes and OpenShift. The concepts help to structure and manage the authorization logic in these container platforms more clearly.

ACDC in practice with Kubernetes and OpenShift

In Kubernetes and OpenShift, permissions are based on Role-Based Access Control (RBAC). The ACDC model provides a high-level thinking framework to better design these RBAC rules.

Attribute in Kubernetes

The Attributes are the core elements defined in the RBAC configuration:

  • Subject Attributes: These are the identities. In Kubernetes these are:
  • User: A human user.
  • Group: A group of users.
  • ServiceAccount: A pod or application that accesses the API.
  • Object Attributes: The resources accessed:
  • Pods, Deployments, Services, Secrets, etc.
  • Action Attributes: The operations that are allowed to be performed:
  • get, list, watch, create, update, delete, exec.

These attributes are bundled into Roles and ClusterRoles, which determine which actions are allowed on which resources.

Context und Constraints in OpenShift

The Context and Constraints are particularly important in OpenShift because the platform offers advanced security features:

  • Namespace as Context: A namespace is a perfect example of a context. A RoleBinding binds a Role to a subject within a specific namespace. This automatically limits the validity of the authorization to this context.
  • Security Context Constraints (SCCs): These are the ultimate constraints in OpenShift. SCCs regulate what a pod can do, e.g. E.g. which volumes it can use, whether it can run as root or whether it can use privileged containers. An SCC is a collection of constraints that ensure that the actions of a pod (the ServiceAccount) comply with security policies.
  • Network Policies: These define how pods are allowed to communicate with each other and with external endpoints. They serve as constraints in the context of the network.

ACDC im Design-Workflow

The ACDC model helps us decompose a permission request like the following and translate it into RBAC configurations:

“A team member (subject) is allowed to update (action) deployments (object) in their development namespace (context), but only if the containers are not running as root (constraint).”

  • Attributes: User, Deployment, Update Action.
  • Context: The specific namespace.
  • Definition: Role for updating deployments.
  • Constraints: The Security Context Constraint that prevents the pod from running as root and the RoleBinding in the specific namespace that restricts permission to that context.

By applying this model, we can develop a clear, readable and secure permissions strategy for our Kubernetes and OpenShift environments that goes far beyond simple Admin vs. User roles.