Security Architecture¶
Security in Digital Rebar Provision is layered across authentication, authorization, secret storage, and network exposure. This section explains why DRP is designed the way it is from a security perspective.
In This Section¶
- Authentication & Authorization — RBAC model: users, roles, tenants, identity providers
- Token Mechanics — How user tokens and machine tokens are issued and validated
- Secure Parameters — Encrypting secrets internally and integrating with external vaults
- Network Security — Port exposure, firewall design, and TLS
Security Model Summary¶
| Layer | Mechanism |
|---|---|
| Identity | Users, machine tokens, certificates, AD/SAML/OIDC |
| Authorization | Role-Based Access Control (RBAC) with Claims, Roles, Tenants |
| Secrets | Internal encrypted parameters or external backends (Vault, Azure KV, AWS SM) |
| Network | TLS on API (8092), firewall rules per port/service |
| Machine Auth | Short-lived tokens generated at template expansion time |
See Also¶
- Infrastructure Deployment — Where DRP endpoints run and how they are networked
- Administrator Guide — Configuring authentication, certificates, and firewall rules
Authentication and Authorization Architecture¶
DRP uses a layered authentication and authorization model built around:
- Users — individual accounts with username/password or token credentials
- Roles — collections of permissions (claims) granted to users
- Tenants — namespaced scopes that partition access to DRP objects
- Identity Providers — external auth systems (Active Directory, SAML/OIDC) that map external users to DRP roles
Authentication Methods¶
| Method | Description | Use Case |
|---|---|---|
| Username/Password | Native DRP user credentials | Simple deployments, admin access |
| Token | Short-lived or long-lived API tokens | Automation, CI/CD |
| Certificate | Client TLS certificates | Machine-to-machine, high-security |
| Active Directory (AD) | LDAP-based external auth | Enterprise environments |
| SAML/OIDC | Identity provider federation | SSO, enterprise IdP integration |
Authorization Model¶
DRP uses Role-Based Access Control (RBAC):
- Claims — atomic permissions:
Create,Read,Update,Delete,Actionon specific object types - Roles — named bundles of claims
- Users — assigned one or more roles
- Tenants — scope a user's role to a subset of DRP objects
Superuser vs. Scoped Users¶
The default superuser role has unrestricted access. Scoped users are limited to the object types
and tenants permitted by their assigned roles. This is important in multi-tenant or multi-team deployments.
Secure Parameter Store¶
Sensitive configuration values (cloud credentials, secrets) can be stored in external secret backends rather than DRP's internal store:
- HashiCorp Vault — enterprise secret management
- Azure Key Vault — Azure-native secrets
- AWS Secrets Manager — AWS-native secrets
- Command backend — custom shell-script-based secret retrieval
DRP fetches secrets at task execution time, avoiding plaintext storage in profiles or parameters.
Design Considerations¶
- Use tenants to separate team or project access in shared environments
- Use certificates or tokens (not passwords) for automation service accounts
- Configure SAML/AD in enterprise environments to centralize identity management
- Store all secrets in an external backend in production deployments
Operational Details¶
For step-by-step configuration of authentication, see Authentication Configuration.
For RBAC model reference, see Role Model, User Model, Tenant Model.