# Administration Operating at scale requires strong control and configuration. OpsMx provides capabilities to manage users, roles, environments, policies, and system settings across the platform. Security actions must be controlled, auditable, and compliant. OpsMx enables policy-driven approvals, human-in-the-loop workflows, audit trails, and evidence generation so organizations can enforce governance and meet regulatory and compliance requirements. Policy & Governance in OpsMx ISD for Argo is a comprehensive security and compliance layer built directly into the GitOps delivery pipeline. It gives DevSecOps teams the controls they need to enforce security standards, manage access, automate compliance checks, and maintain a complete audit trail — all without disrupting developer velocity or existing Argo CD workflows. #### Why Policy & Governance in OpsMx ISD for Argo Open-source Argo CD is powerful for GitOps-based delivery but lacks enterprise-grade policy enforcement, centralized access control, and compliance automation out of the box. As organizations scale Argo CD across multiple clusters and teams, the absence of these controls creates significant security and audit risk. ISD for Argo helps DevOps and security teams create policies and implement security and compliance controls in the GitOps-style delivery environment. Without a governance layer, organizations face: * No centralized enforcement of deployment rules across clusters and teams * Manual, error-prone approval processes for change management * Inability to prove compliance during audits without significant manual effort * Uncontrolled access to Argo CD instances and Kubernetes clusters * No automated blocking of non-compliant or vulnerable deployments OpsMx ISD for Argo addresses all of these with a unified, automated Policy & Governance module. It is used because: * **Argo CD alone lacks enterprise policy enforcement** — ISD adds the governance layer that production-grade enterprises require * **Manual compliance is unsustainable at scale** — automated policy checks replace spreadsheets, email approvals, and tribal knowledge * **Audit readiness must be continuous** — every gate decision, approval, and exception is logged automatically, making regulatory audits straightforward * **Multi-cluster GitOps creates governance complexity** — ISD centralizes policy enforcement across all Argo instances from a single control plane * **Developer velocity cannot be sacrificed** — policies are automated so security checks run in the background without blocking teams unnecessarily #### Key Capabilities **1. Authentication & Single Sign-On (SSO)** Support for OAuth2.0, OpenID Connect, and SAML-based authentication to simplify secure user access for Argo CD. Enable native integration with CNOE (Cloud-Native Open Enterprise) for seamless security enforcement. Supported SSO providers include: | Provider | Protocol | | --------------------- | --------------- | | Okta | SAML 2.0 / OIDC | | GitHub | OAuth2.0 | | GitLab | OAuth2.0 | | Microsoft (Azure AD) | OIDC | | LinkedIn | OAuth2.0 | | LDAP | LDAP | | Generic OIDC Provider | OpenID Connect | *** **2. Role-Based Access Control (RBAC)** Enforce granular Role-Based Access Control (RBAC) to manage permissions securely. Argo CD offers Role-Based Access Control (RBAC) to provide least privilege access to users. It supports integration with third-party authentication and authorization providers. RBAC in ISD for Argo allows organizations to: * Assign read/write permissions per team across Argo CD Custom Resource Definitions (CRDs) * Restrict deployment capabilities by cluster, environment, or application * Separate developer, QA, and operations roles with distinct permission scopes * Enforce multitenancy — ensuring teams only see and act on applications they own * Add manual and automated gates to the delivery process to enforce security policies, change controls, and application readiness checks. *** **3. Secrets Management** Securely source, store, and deliver secrets on demand and just-in-time to applications and services. Ensure secrets are safely distributed in workflow orchestration, reducing exposure risks. Supported secrets backends include: | Backend | Notes | | ----------------------- | ----------------------------------------------------- | | **Kubernetes Secrets** | Default — secrets stored within the cluster namespace | | **HashiCorp Vault** | Enterprise secret management | | **AWS Secrets Manager** | Cloud-native AWS secret storage | | **Azure Key Vault** | Azure-native secret management | | **CyberArk** | Enterprise privileged access management | *** **4. mTLS & Network Security** Secure services with mTLS (mutual TLS) and pre-shared certificates, preventing unauthorized access. This ensures all communication between ISD components, Argo instances, and connected Kubernetes clusters is encrypted and mutually authenticated — blocking unauthorized interception or impersonation. *** **5. Policy Enforcement via Open Policy Agent (OPA)** ISD has integrations with Open Policy Agent (OPA), using which it can execute and validate SDLC policies. Define and enforce Policy-as-Code using the Open Policy Agent (OPA). Use built-in rules or create custom policies tailored to your organization's standards. Policies are enforced at every deployment gate — automatically evaluating whether a release meets the defined criteria before it proceeds. **Standard compliance policies supported out of the box:** Standard compliance policies as implemented by large and mature IT organizations include: configuring deployment freeze time or blackout window, failing a deployment if approvals are not in place, pre-deployment checks such as container images should use specific base images, TLS requirements, load balancer port configurations, images should not have CVEs, and images deployed must have passed manual or automated tests. | Policy Type | Description | | -------------------------- | -------------------------------------------------------------------------------------------- | | **Blackout Window** | Block all deployments during defined freeze periods (e.g., quarter-end, maintenance windows) | | **Approval Gate** | Fail deployment if required approvals are not in place | | **CVE Gate** | Block images with CVEs above a defined severity threshold | | **Base Image Policy** | Enforce use of approved base images (e.g., UBI8) only | | **TLS Enforcement** | Require TLS 3.0 compliance on all service endpoints | | **Port Policy** | Enforce load balancer ports to run within specified ranges | | **Test Verification Gate** | Block deployments unless manual or automated tests have passed | | **Custom OPA Policies** | Define any organization-specific rule in Rego policy language | *** **6. Deployment Firewall** OpsMx enables users to enforce policies for compliance and security controls using a Deployment Firewall. Deployment Firewall works on three parameters — policies or deployment/release rules, data from your DevOps tools, and the enforcement layer where the policy gets orchestrated using the data that is fed into the policy. Automatically approve, block, or escalate deployments based on real-time risk signals, scan results, or custom-defined triggers. Block risky or non-compliant releases without frustrating developers. The Deployment Firewall evaluates a deployment against: * Vulnerability scan results (SAST, SCA, DAST, container image scans) * Approval and change management status * Policy compliance checks from OPA * Infrastructure compliance checks (image integrity, port configuration, TLS) * Blackout window schedules The deployment firewall supports DevOps platforms such as Jenkins, Argo, and Spinnaker, with support for GitHub Actions and GitLab also available. *** **7. Automated Compliance Checks** The security and governance module can be used to automatically enforce security, approval, and deployment policies in the CI/CD process. It allows easy implementation of governance to make the SDLC compliant with industry best practices and standards. DevSecOps teams can enforce security and policy checks into their deployment and delivery processes to release risk-free features. Compliance frameworks supported: | Framework | Coverage | | ----------- | --------------------------------------------------------------------------------------------------------- | | **SOX** | Change management controls, audit trails, and approval gates | | **HIPAA** | Access control, data protection, and deployment logging | | **GDPR** | Data governance and policy-driven access restrictions | | **PCI DSS** | Vulnerability scanning gates, image integrity, and audit logs | | **SOC 2** | SOC 2 compliance tags added to security policies within Delivery Shield for improved security governance. | *** **8. Audit Trails & Compliance Reporting** Automatically log every policy decision, deployment action, and exception approval. Pass audits with confidence — no more compliance chaos. Automatically log every gate decision — approvals, blocks, rollbacks, and exceptions — creating a complete, real-time audit trail. The audit module captures: * Who deployed what, to which cluster, and when * Every policy check result — pass, block, or escalate * Approval decisions with approver identity and timestamp * Exception requests, approvals, and expiry notifications * Rollback events with root cause context While it is important to audit deployments and workflow activities, for enterprises, user activity audits are equally important. OpsMx provisions these reports out of the box to not only maintain the track record of users across Argo instances but also on OpsMx Secure CD for Argo. *** **9. Exception Management** Allow teams to request and approve temporary policy exceptions — with built-in reminders for expiry and follow-up with alerts and notifications via Slack and Email. This enables teams to handle urgent deployments without permanently weakening policy controls — exceptions are time-bound, logged, and automatically flagged for review on expiry. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.opsmx.com/administration/administration.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.