3.1 Control Plane vs Agent Execution Plane
3.2 Project Scope Model
3.3 Data Flow: Source -> Release -> Pipeline -> Logs/Artifacts
3.4 Runtime Configuration Layers (global / project / environment)
3.5 Pipeline Execution Semantics
3.6 Release Governance Path
3.7 Rollback Architecture (Policy-driven)
3.8 Security and Trust Boundaries
3.9 State and Persistence Model
3.10 Scalability Model
3.11 Failure Modes and Recovery Patterns
3.12 Why This Architecture Works in Practice
7.3 OAuth Login Settings (GitHub/GitLab)
Orbnetes deployment and release orchestration documentation for operators and platform teams.
OAuth configuration allows users to authenticate using external identity providers.
Typical setup flow:
- Create OAuth app in provider (GitHub/GitLab).
- Copy client ID / client secret into Orbnetes config.
- Configure exact callback URL.
- Enable provider in Orbnetes.
- Test login with non-admin account.
- Confirm post-login approval workflow (if enabled).
Operational behavior (recommended model):
- First OAuth login creates a user in pending access state.
- Admin reviews and grants permissions before full access.
- Linked OAuth identities can be managed in user/profile connections.
Common misconfigurations:
- callback URL mismatch,
- wrong client secret,
- provider disabled in Orbnetes but used in UI,
- missing at least one active login method policy handling.
Best practices:
- Enable only providers actually used by your organization.
- Rotate OAuth secrets periodically.
- Document callback URLs centrally per environment (dev/stage/prod).