Blue Whale CMDB in Production: The Permission Problem Nobody Warns You About

Over the years of doing custom development for Blue Whale CMDB, the most common request I've encountered isn't "add a field" or "change a display"—it's permissions. Out of the box, a fresh CMDB install ships with a single user, and every operation goes through that same account. The permission granularity is so coarse it's practically useless. The moment an enterprise moves to production, the security team's first question is "Who can delete models? Who can modify instances?"—and you can't answer. The community edition doesn't even have user or role management. Want to plug into your company's unified OIDC/OAuth2 for single sign-on? You're building it from scratch.

I recently spent over a month building this out end to end, from backend to frontend. This isn't a patch—it's a standalone module. Today I'm breaking down the process.

What It Looks Like After Building It

Compared to the native CMDB, there are four core capabilities added:

• **Standalone User Management Center**: Create, edit, query, and disable users—all from a single page. No more jumping between external systems.
• **Role and Permission Assignment**: No limit on the number of custom roles. I've actually configured roles like "DBA," "Network Administrator," and "Application Owner," where each role can independently toggle CRUD permissions on models, instances, business objects, and even system-level features.
• **OIDC Authentication**: Native integration of the OpenID Connect protocol, connecting to enterprise unified identity providers like Authing and Okta, with single sign-on working out of the box.
• **Brand-New Frontend Interface**: An admin interface built from the ground up on the Vue.js stack. I iterated on the interaction logic repeatedly, and administrators find it significantly more intuitive than the native UI.

What Actually Changed at the Technical Level

For this customization, I'd say the core difficulty isn't any single point—it's that the changes span the entire tech stack. API services, data flow, middleware, frontend routing, state management, containerized deployment—every layer had to be touched, and they're all tightly interdependent.

Backend (Golang)

• Added a complete User Management service module. Over 2,000 lines of core logic were written across coreservice and web_server to handle all user, role, and permission-related API requests.
• Wrote a dedicated oidc.go service for OIDC integration and refactored login.go to dynamically handle multiple login modes.
• Designed a new user_management data model with a companion user_management_init.go database migration script. I hit a snag: the migration script lacked proper compatibility handling, and the canary environment blew up. I had to add rollback logic before things stabilized.

Frontend (Vue.js)

• Created a new user-management view directory containing seven core Vue components—user list, role management, permission configuration, user form, and more—totaling over 1,500 lines of code.
• Permission state is complex, so I split it into two dedicated Vuex modules—role-permission.js and user-management.js—handling the fetching, mutation, and caching of permission data.
• Also wrote a permission.js utility and a v-permission custom directive. Controlling element visibility in templates is now a one-line directive instead of scattering v-if conditions everywhere—much cleaner.

Operations & Deployment (Helm)

To make the whole thing run directly in a containerized environment, I updated dozens of Helm Chart configuration files (values.yaml, configmap.yaml, and others) to ensure the new services and configurations are properly picked up by Kubernetes. This part isn't a huge amount of work, but it's easy to miss something. Miss one configmap field and you get a 502 in production.

Why I Think This Was Worth Doing

Technology ultimately has to deliver on the business side. From my hands-on testing, the changes this brings are very concrete:

• Security: Role-based, precise authorization following the principle of least privilege keeps the risk of accidental operations and unauthorized access very low.
• Efficiency: Once permissions are clearly delineated, administrators no longer need to manually edit config files, saving a significant amount of daily ops time.
• Integration: Once connected to the enterprise's existing authentication infrastructure, the employee login flow is simplified, and audit logs can be consolidated in one place.

If You Need Something Similar

I've been in the CMDB space for several years and have delivered projects like this from 0 to 1. If you have further needs—developing new business feature modules, integrating with other internal enterprise systems, deep performance optimization and secondary development, or professional technical consulting—feel free to reach out.

📧 Email: [email protected]

💬 WeChat: winnielove2020