Recommended Secure Configuration (RSC) guidance
This document supports FedRAMP Rev5 RSC compliance for H2O MLOps on H2O-GOV Managed Cloud. For general product documentation, see What is H2O MLOps?.
1. Purpose and scope
This document provides agency-facing guidance for securely configuring H2O MLOps within the H2O-GOV Managed Cloud in accordance with FedRAMP Rev5 Recommended Secure Configuration (RSC) requirements. It covers the security settings that agency administrators can configure through the MLOps product UI and APIs within their tenant.
H2O MLOps is a platform for deploying, monitoring, and managing machine learning models in production. In the H2O-GOV Managed Cloud deployment model, the platform infrastructure is fully managed by H2O Managed Cloud Operations. This includes identity provider configuration, encryption, network security, container security, and all deployment-level platform settings.
Agency administrators interact with H2O MLOps exclusively through the product UI and APIs. This document covers only the security settings within that scope.
In-scope components (from the agency perspective):
| Component | Description | Agency interaction |
|---|---|---|
| MLOps UI | Web-based administration and management console | Primary admin interface |
| gRPC Gateway | API gateway for HTTP/Connect access | API endpoint for programmatic access |
| Python Client | Client SDK for programmatic MLOps access | SDK for automation and scripting |
| Monitoring Frontend | Model monitoring dashboards | Dashboard creation and viewing |
2. Audience and assumptions
Intended audience:
- Agency administrators responsible for MLOps tenant administration
- Agency security architects reviewing the security posture of their MLOps tenant
- Agency auditors and assessors reviewing compliance posture
Assumptions:
- H2O MLOps is deployed on the H2O-GOV Managed Cloud, with infrastructure managed by H2O Managed Cloud Operations
- Agency administrators interact with MLOps through the product UI, gRPC/Connect APIs, and/or the Python Client SDK
- Agency administrators do not have access to infrastructure-level tooling — all platform configuration is managed by H2O Ops
- Identity provider, MFA, encryption, and network controls are managed by H2O Managed Cloud Operations
3. Definitions and account taxonomy
H2O MLOps uses a delegated identity model. There are no local user accounts or passwords stored within the platform itself. All human authentication flows through the identity provider managed by H2O Managed Cloud Operations, and all authorization decisions are made by the platform's Authorization Server.
| Account type | Product term / role name | Scope | How provisioned | Notes |
|---|---|---|---|---|
| Top-level admin | admin / super-admin | Tenant-wide | SSO / role mapping | Controls platform-wide settings, RBAC policies, workspace creation, and all security configurations accessible through the UI and APIs. FedRAMP: AC-2, AC-6. |
| Privileged account | workspace-owner / personal-workspace-owner | Workspace / Project | SSO + role binding | Manages workspace-level resources: deployments, experiments, models, monitoring dashboards. Assigned via the Authorization Server APIs. FedRAMP: AC-2(7), AC-6(1). |
| Standard user | Authenticated user | Workspace (as granted) | SSO | Can view and interact with resources within granted workspaces. Access determined by role bindings. FedRAMP: AC-2. |
| MLOps admin group | mlops-admin (platform group) | All workspaces | SSO + platform group membership | Members are granted read and write access to all MLOps resources across all workspaces (except the appstore workspace, which is explicitly denied). The group also grants listing all workspaces and reading role bindings. Tightly control membership. FedRAMP: AC-2, AC-6. |
Key architectural note: Because MLOps has no local user database, account lifecycle operations (creation, modification, suspension, removal) are performed at the identity provider level (managed by H2O Ops). MLOps reflects identity provider state on each authentication event.
4. Recommended secure defaults summary
The following table summarizes the security posture for H2O MLOps as deployed on H2O-GOV Managed Cloud. It identifies which settings are managed by H2O Ops (no agency action needed) and which can be configured by agency administrators through the UI or APIs.
| Control area | Security posture | Agency configurable? | FedRAMP controls |
|---|---|---|---|
| Identity and access | SSO integration; no local passwords | No — Managed by H2O Ops | AC-2, IA-2, IA-8 |
| Authentication | SSO with secure token validation | No — Managed by H2O Ops | IA-2, IA-5, SC-23 |
| MFA | Enforced at the identity provider level | No — Managed by H2O Ops | IA-2(1), IA-2(2) |
| Authorization / RBAC | Workspace-based isolation with policy engine | Yes — Agency configures workspace structure, roles, and role bindings via UI and APIs | AC-3, AC-6 |
| Scoring endpoint auth | NIST-compliant passphrase hashing or OIDC per deployment | Yes — Agency sets per-deployment security type and passphrase via UI or API | IA-5, SC-13 |
| Audit trail | Enabled by default; events captured for all API operations | No — Managed by H2O Ops (agency can view audit events) | AU-2, AU-3 |
| Encryption in transit | All communications encrypted via TLS | No — Managed by H2O Ops | SC-8, SC-13 |
| Encryption at rest | Cloud provider encryption for all stored data | No — Managed by H2O Ops | SC-28 |
| Container security | Hardened container images; FIPS 140 cryptography; non-root execution | No — Managed by H2O Ops | CM-6, SC-2, SI-7 |
| Session management | Encrypted sessions; secure cookies | No — Managed by H2O Ops | SC-23 |
| User inactivity timeout | Configured at the platform level | No — Managed by H2O Ops | AC-11 |
| Workspace management | Create, update, delete, archive workspaces | Yes — Agency manages workspace lifecycle via UI and APIs | AC-4 |
| Runtime management | Create, update, disable, deprecate custom runtimes | Yes — Agency manages custom runtimes via UI, API, or Python Client | CM-7 |
| Deployment resource limits | CPU and memory limits per deployment | Yes — Agency sets per-deployment resource limits via UI or API | SC-5 |
| User and group management | Add/remove members, create groups, assign roles | Yes — Agency manages users and groups via Admin Center UI | AC-2 |
5. Top-level administrative accounts: secure access, configuration, operation, and decommissioning
5.1 Secure access
H2O MLOps uses SSO exclusively for all human authentication. There are no local admin passwords, no built-in default accounts, and no backdoor access mechanisms within the application. Admin status is derived from SSO role claims, which means the identity provider is the single source of truth for all administrative access.
Identity provider and MFA configuration is managed by H2O Managed Cloud Operations. Agency administrators benefit from SSO and MFA protection without needing to configure it.
All interactive users authenticate via SSO with MFA enforced at the identity provider layer. There is no fallback to local authentication.
The platform's Authorization Server handles all authorization, evaluating policies against user attributes and workspace membership. Agency administrators manage authorization through the platform UI and APIs:
- Admin Center → Member Management: Add/remove platform members, promote/demote to admin
- Admin Center → Custom Groups: Create and manage user groups
- gRPC/Connect APIs:
CreateRoleBinding,DeleteRoleBinding,ListRoleBindingsfor programmatic role assignment
Role-based access control is enforced through the workspace-based authorization model. Agency administrators manage role assignments through the UI and APIs.
5.2 Secure configuration
5.2.1 Minimize admin accounts
Assign the admin role to the fewest users necessary. Use workspace-owner for day-to-day project management. The role hierarchy is:
super-admin— Platform-wide configuration changes, all workspace accessadmin— Workspace and user managementmlops-admin(platform group) — Read/write access to all MLOps resources across all workspaces (exceptappstore). Limit membership to personnel requiring cross-workspace administrative access.workspace-owner— Project-level operations within assigned workspacesStandard user— Read/write within granted workspaces only
5.2.2 Manage role bindings
Use the Authorization Server APIs to grant least-privilege access:
CreateRoleBinding— Assign a role to a user or group on a specific workspaceDeleteRoleBinding— Revoke a role assignmentListRoleBindings— Enumerate current role assignments for access reviewBatchCreateRoleBindings/BatchDeleteRoleBindings— Atomic bulk operations
Role bindings follow the pattern: assign a role (for example, roles/workspace-owner) to a subject (for example, users/<UUID>) on a resource (for example, //workspaceserver/workspaces/<UUID>).
Least-privilege access is implemented through granular role bindings on workspace resources.
5.2.3 Manage custom roles
Agency administrators can create custom roles with specific permissions using the Role Service APIs:
CreateRole— Define a new role with specific action statementsAddActionStatements/RemoveActionStatements— Modify role permissionsListRoles— Enumerate all defined roles
Actions follow the format mlops/<resource>/<operation> where resources include: workspaces, artifacts, datasets, deployments, endpoints, batch-scoring-jobs, experiments, registered-models, runtimes, tags, and monitoring.
5.2.4 Manage permission presets
Permission presets are reusable templates for role assignments:
CreatePermissionPreset— Create a template that auto-assigns a role to a subject on matching resources- Supports wildcard resource patterns (for example,
//workspaceserver/workspaces/*for all workspaces)
5.3 Secure operation
5.3.1 Audit trail
The audit trail is enabled by default (managed by H2O Ops). Audit events include: principal (user ID), source IP, user agent, action, resource, status code, and timestamp.
Key events captured:
- Failed authentication attempts
- Workspace creation/deletion
- Deployment security configuration changes
- Model deployment and undeployment
- Role binding changes
The audit trail captures the required audit event types with sufficient detail for incident investigation.
5.3.2 Periodic access reviews
Use the Authorization Server gRPC/Connect APIs to enumerate current RBAC state:
ListRoles— All defined rolesListRoleBindings— User-to-role mappingsListWorkspaces— Active workspaces and ownership
Call these APIs programmatically via the Python Client or directly via gRPC/Connect for automated compliance reporting.
Periodic access reviews verify that users retain only necessary privileges.
5.3.3 Monitor deployments
Agency administrators can monitor model health and security through:
- MLOps UI: Admin → MLOps → Deployments (view all deployments across workspaces, including security status)
- Monitoring Frontend: Ownership-based dashboards for model health, drift, and operational metrics
- Python Client:
client.deployments.list()anddeployment.monitoringfor programmatic access - Monitoring APIs:
GetModelHealthMetrics,GetModelDriftMetrics,GetModelOperationalSummaryMetrics
5.4 Secure decommissioning
-
Disable admin accounts. Request removal of admin roles via H2O Managed Cloud Operations. The next token refresh or session expiry revokes admin privileges.
-
Delete data. Use the Storage APIs or Python Client to delete experiments, models, and datasets:
workspace = client.workspaces.get(name="my-workspace")for deployment in workspace.deployments.list():deployment.delete()for experiment in workspace.experiments.list():experiment.delete()for model in workspace.models.list():model.delete()The cleanup task (runs every 24 hours) permanently removes soft-deleted data after the grace period.
-
Delete workspaces. Use
DeleteWorkspaceto soft-delete workspaces (30-day retention for recovery). -
Request tenant decommissioning. Contact H2O Managed Cloud Operations to complete infrastructure-level cleanup.
Decommissioning procedures ensure complete removal of access and data.
6. Security settings managed by top-level administrative accounts
This section documents all security settings that agency administrators can view or modify through the MLOps UI and APIs. These are organized by security domain.
6.1 Deployment scoring endpoint security (TL-01 through TL-02)
These settings control how scoring endpoints (model inference APIs) are authenticated. Agency administrators configure these per-deployment through the UI or API.
| Setting ID | Setting name | Recommended value | Platform default | Security impact | FedRAMP | How to change |
|---|---|---|---|---|---|---|
| TL-01 | Deployment scoring security type | PBKDF2 or OIDC | Per platform configuration (set by H2O Ops) | Controls the authentication method for each deployment's scoring endpoint. Available options: DISABLED (not recommended), PASSPHRASE_HASH_TYPE_PLAINTEXT (dev only), PASSPHRASE_HASH_TYPE_PBKDF2 (recommended — NIST SP 800-132 compliant hashing), AUTHORIZATION_PROTOCOL_OIDC (recommended — token-based). | IA-5, SC-13 | MLOps UI → Deployment → Security tab; API: UpdateDeployment with deployment.security field mask; Python Client: deployment.update(security_options=...) |
| TL-02 | Deployment scoring passphrase | Strong, unique passphrase per deployment | None (user-set) | The passphrase protects the scoring endpoint. Weak passphrases allow brute-force access. When PBKDF2 is selected, the passphrase is hashed using NIST SP 800-132 compliant parameters. The passphrase is not retrievable after being set (stored as hash). | IA-5 | MLOps UI → Deployment → Security tab; API: UpdateDeployment with deployment.security field mask; Python Client: deployment.update(security_options=...) |
Discovering available security options: Use the ConfigService API to discover which security types are activated in your environment:
ListSecurityOptionTypes— Returns the list of activated security optionsGetDefaultSecurityOptionType— Returns the default security option for new deployments
Security type transitions: The API enforces valid transitions between security types:
- Any type → PBKDF2 or OIDC (upgrade path)
- PBKDF2 ↔ Plaintext (bidirectional)
- PBKDF2 or Plaintext → OIDC (upgrade path)
- OIDC → PBKDF2 or Plaintext (downgrade path)
- Updated passphrase must not be blank
Example: Set PBKDF2 security on a deployment via Python Client:
import h2o_mlops
client = h2o_mlops.Client(
gateway_url="https://mlops-api.example.com",
token_provider=token_provider,
)
workspace = client.workspaces.get(name="my-workspace")
deployment = workspace.deployments.get(name="my-deployment")
# Update deployment security to PBKDF2
deployment.update(
security_options={
"passphrase": "strong-unique-passphrase-here",
"hash_algorithm": "PBKDF2",
}
)
Scoring endpoints are protected by NIST-compliant passphrase hashing or OIDC token validation. Agency administrators are responsible for selecting strong authentication for each deployment.
6.2 Workspace and access control (TL-03 through TL-05)
These settings control workspace structure, role assignments, and access boundaries.
| Setting ID | Setting name | Recommended value | Platform default | Security impact | FedRAMP | How to change |
|---|---|---|---|---|---|---|
| TL-03 | Workspace structure | Organize by team, project, or classification level | No workspaces (must create) | Workspaces are the primary isolation boundary in MLOps. All resources (deployments, models, experiments, datasets) are scoped to a workspace. Users can only access resources in workspaces where they have been granted a role. | AC-4 | MLOps UI → Admin → Manage Workspaces; API: CreateWorkspace, UpdateWorkspace, DeleteWorkspace; Python Client: client.workspaces.create() |
| TL-04 | Role bindings | Assign least-privilege roles per workspace | No role bindings (must configure) | Role bindings determine which users can access which workspaces and what operations they can perform. Over-permissive bindings can lead to unauthorized data access. | AC-6 | Admin Center → Member Management; API: CreateRoleBinding, DeleteRoleBinding, BatchCreateRoleBindings; Python Client: low-level authz API |
| TL-05 | Custom groups | Create groups aligned with organizational roles | No custom groups | Groups simplify role assignment by allowing batch membership management. All members of a group inherit the group's role bindings. | AC-2 | Admin Center → Custom Groups |
Change procedure for TL-03 (Workspace structure):
- Plan workspace structure based on teams, projects, or data classification levels.
- Create workspaces via UI or API:
workspace = client.workspaces.create(name="data-science-team-a",description="Workspace for Data Science Team A models")
- Assign workspace owners and members via role bindings (TL-04).
Change procedure for TL-04 (Role bindings):
- Identify which users need access to which workspaces.
- Assign roles via the API:
CreateRoleBinding(resource="//workspaceserver/workspaces/<UUID>", subject="users/<UUID>", role="roles/workspace-owner") - Periodically review bindings using
ListRoleBindings(see Periodic access reviews).
Workspace isolation and role-based access control enforce data separation and least-privilege access.
6.3 User and group management (TL-06 through TL-07)
These settings control platform membership and admin role assignments.
| Setting ID | Setting name | Recommended value | Platform default | Security impact | FedRAMP | How to change |
|---|---|---|---|---|---|---|
| TL-06 | Platform members | Add only authorized personnel; remove departing staff promptly | No members beyond initial admin | Unauthorized platform members could access tenant resources. Stale accounts for departed personnel create orphaned access. | AC-2 | Admin Center → Member Management (add, remove, promote/demote) |
| TL-07 | Admin role assignments | Minimize admin count; use workspace-owner for day-to-day operations | Single initial admin | Excessive admin accounts increase the attack surface. Admins have tenant-wide access to all workspaces and settings. | AC-6(1) | Admin Center → Member Management (promote/demote admin status) |
6.4 Runtime management (TL-08)
This setting controls custom runtime creation and lifecycle.
| Setting ID | Setting name | Recommended value | Platform default | Security impact | FedRAMP | How to change |
|---|---|---|---|---|---|---|
| TL-08 | Custom runtimes | Only create runtimes from trusted, verified images | Platform-provided runtimes | Custom runtimes execute model inference code. Untrusted runtime images could introduce vulnerabilities or malicious code. Disable or deprecate unused runtimes. | CM-7, SI-7 | MLOps UI → Admin → MLOps → Runtimes; API: CreateRuntime, UpdateRuntime, DisableRuntime, DeprecateRuntime, DeleteRuntime; Python Client: workspace.runtimes.create(), .disable(), .deprecate() |
Runtime lifecycle management:
CreateRuntime— Add a custom runtime with specified image and environment variablesEnableRuntime/DisableRuntime— Control whether a runtime can be used for new deploymentsDeprecateRuntime— Mark a runtime as deprecated (still usable but flagged)DeleteRuntime— Permanently remove a runtime definitionUpdateRuntime— Modify runtime properties (display name, description, environment variables)
7. Security settings managed by privileged accounts
7.1 Authorization model
H2O MLOps uses a workspace-based authorization model. The platform's Authorization Server evaluates policies against user attributes and workspace membership to determine access.
The RBAC action vocabulary follows the format mlops/<resource>/<operation> where resources include: workspaces, artifacts, datasets, deployments, endpoints, batch-scoring-jobs, experiments, registered-models, runtimes, tags, and monitoring. Operations include: GET, CREATE, LIST, UPDATE, DELETE, plus resource-specific operations (PAUSE, RESUME, UPGRADE_RUNTIME_IMAGE, CANCEL, TAG, LINK_INTO_PROJECT).
7.2 Workspace-level security settings
Workspace owners or privileged (non-admin) users manage these settings within their authorized scope.
| Setting ID | Setting name | Recommended value | Default value | Security impact | FedRAMP | How to view / change |
|---|---|---|---|---|---|---|
| PR-01 | Deployment scoring security type | PBKDF2 or OIDC | Per platform default (TL-01) | Per-deployment authentication method for scoring endpoints. Plaintext or disabled security exposes model endpoints to unauthorized access. | IA-5 | MLOps UI → Deployment → Security tab; API: UpdateDeployment with deployment.security field mask |
| PR-02 | Deployment scoring passphrase | Strong, unique passphrase per deployment | None (user-set) | The passphrase protects the scoring endpoint. Weak passphrases allow brute-force access. When PBKDF2 is selected, the passphrase is hashed using NIST-compliant parameters. | IA-5 | Not retrievable (stored as hash); MLOps UI → Deployment → Security; API: UpdateDeployment |
| PR-03 | Deployment resource limits | Set both CPU and memory limits | Platform-defined defaults | Without resource limits, a single deployment can exhaust platform resources (denial-of-service). Set explicit limits per deployment. | SC-5 | MLOps UI → Deployment → Resources; API: UpdateDeployment with resource spec field mask; Python Client: deployment.update(kubernetes_options=...) |
| PR-04 | Deployment environment variables | Only set required variables; avoid embedding secrets | None | Environment variables are visible to deployment containers. Embedding secrets in environment variables risks exposure through logs or process listings. | CM-6 | MLOps UI → Deployment settings; API: UpdateDeployment with deployment.environment_variables field mask; Python Client: deployment.update(environment_variables=...) |
| PR-05 | Deployment CORS origins | Restrict to specific domains if cross-origin scoring is needed | None (no cross-origin access) | Per-deployment CORS controls which browser origins can call the scoring endpoint. Overly permissive CORS exposes scoring endpoints to cross-origin attacks. | SC-23 | API: UpdateDeployment with deployment.cors field mask; Python Client: deployment.update(cors_origins=...) |
| PR-06 | Deployment monitoring | Enable monitoring for production deployments | Disabled | Monitoring tracks model health, drift, and operational metrics. Without monitoring, model degradation goes undetected. | SI-4 | MLOps UI → Deployment → Monitoring; API: UpdateDeployment with deployment.monitoring field mask; Python Client: deployment.update(monitoring_options=...) |
| PR-07 | Monitoring dashboard ownership | Default (enabled) | Enabled | Users see only their own monitoring dashboards and charts. Admins see all. Prevents cross-tenant data leakage in the monitoring frontend. | AC-4 | Automatic (code-level default) |
7.3 Data lifecycle operations
Workspace owners can manage the lifecycle of ML artifacts through the UI and APIs:
| Operation | API | Description | Security relevance |
|---|---|---|---|
| Delete experiments | DeleteExperiment, BatchDeleteExperiment | Soft-delete with 15-day grace period (configurable by H2O Ops) | Ensures data can be recovered from accidental deletion; permanent purge after grace period satisfies data retention requirements |
| Delete models | DeleteRegisteredModel, BatchDeleteRegisteredModel | Soft-delete (grace period configured by H2O Ops) | Data can be recovered from accidental deletion; permanent purge after grace period satisfies data retention requirements |
| Delete datasets | DeleteDataset, BatchDeleteDataset | Soft-delete (grace period configured by H2O Ops) | Data can be recovered from accidental deletion; permanent purge after grace period satisfies data retention requirements |
| Recover deleted items | RecoverDeletedExperiment, BatchRecoverDeletedExperiment | Restore soft-deleted experiments within grace period | Provides recovery capability |
| Tag resources | TagExperiment, TagDataset | Apply metadata tags for organization | Supports data classification and governance |
Data retention and deletion are managed through the Storage APIs. Grace periods for permanent purge are configured at the platform level by H2O Ops.
8. Secure defaults on provisioning
8.1 Provisioning model
When a new agency tenant is provisioned on H2O-GOV Managed Cloud, all infrastructure-level security settings are pre-configured by H2O Managed Cloud Operations. Agency administrators then configure tenant-level settings through the UI and APIs.
8.2 Provisioning defaults
The following table shows the default values for agency-configurable settings at initial provisioning.
| Setting ID | Setting name | Default | Recommended value | Secure by default? | Agency action required |
|---|---|---|---|---|---|
| PD-01 | Workspace structure | No workspaces | Organized by team/project/classification | No — must create | Create workspaces and assign roles |
| PD-02 | Role bindings | Initial admin only | Least-privilege assignments | No — must configure | Assign workspace-owner and user roles |
| PD-03 | Scoring endpoint auth | Per platform default | PBKDF2 or OIDC per deployment | Conditional — depends on platform default | Verify and set per-deployment security |
| PD-04 | Custom runtimes | Platform-provided runtimes only | Only trusted, verified images | Yes — platform runtimes are pre-verified | Review before adding custom runtimes |
| PD-05 | Deployment resource limits | Platform-defined defaults | Set per compliance requirements | Partially — defaults exist but may need adjustment | Review and adjust per deployment |
| PD-06 | Deployment monitoring | Disabled | Enabled for production deployments | No — must enable | Enable monitoring for production deployments |
| PD-07 | Platform members | Initial admin only | Only authorized personnel | Yes — minimal by default | Add members as needed |
| PD-08 | Monitoring dashboard ownership | Enabled | Enabled | Yes — isolation by default | None |
8.3 Platform security defaults (managed by H2O Ops)
The following security controls are pre-configured by H2O Managed Cloud Operations and require no agency action:
- SSO authentication with MFA enforcement — all users authenticate via SSO with multi-factor authentication
- Audit trail enabled — all API operations are logged
- Encryption in transit — all communications are encrypted via TLS
- Encryption at rest — all stored data is encrypted using cloud provider mechanisms
- FIPS 140 cryptography — all cryptographic operations use FIPS-validated implementations
- Hardened container images — services run with non-root execution and minimal attack surface
- NIST-compliant password hashing — PBKDF2 parameters meet NIST SP 800-132 requirements
- Secure session management — encrypted sessions with secure cookie attributes and HSTS
- Workspace isolation — enforced by the platform's authorization policies
- Service-to-service authentication — internal services authenticate with validated tokens
9. Comparing current settings to recommended secure defaults
9.1 API-based review methods
Agency administrators can compare their current configuration against this guidance using the MLOps APIs:
Workspace and RBAC review:
import h2o_mlops
client = h2o_mlops.Client(
gateway_url="https://mlops-api.example.com",
token_provider=token_provider,
)
# List all workspaces
for ws in client.workspaces.list():
print(f"Workspace: {ws.name} (owner: {ws.creator})")
# Review role bindings (via low-level authz API)
role_bindings = client._backend.authz.role_binding.list_role_bindings()
for rb in role_bindings:
print(f"Subject: {rb.subject}, Role: {rb.role}, Resource: {rb.resource}")
# Review defined roles
roles = client._backend.authz.role.list_roles()
for role in roles:
print(f"Role: {role.name}")
Deployment security review:
# Check scoring security for all deployments in a workspace
workspace = client.workspaces.get(name="production")
for deployment in workspace.deployments.list():
print(f"Deployment: {deployment.name}")
print(f" Security: {deployment.security_options}")
print(f" State: {deployment.state}")
print(f" Healthy: {deployment.is_healthy}")
Platform configuration discovery:
# Discover available security options (via low-level deployer API)
security_types = client._backend.deployer.config.list_security_option_types()
default_security = client._backend.deployer.config.get_default_security_option_type()
max_replicas = client._backend.deployer.config.discover_deployment_max_replicas()
monitoring_config = client._backend.deployer.config.get_monitoring_config()
9.2 Manual review checklist
Use this checklist for a manual walkthrough of your tenant's security posture.
| Check | Method | Expected result |
|---|---|---|
| Workspaces organized | MLOps UI → Admin → Manage Workspaces | Workspaces exist with clear naming/purpose |
| Role bindings follow least-privilege | API: ListRoleBindings | No excessive admin or cross-workspace access |
| Admin accounts minimized | Admin Center → Member Management | Minimal admin count; most users are workspace-owner or standard |
| Scoring endpoints secured | MLOps UI → Admin → MLOps → Deployments | All production deployments use PBKDF2 or OIDC |
| Custom runtimes reviewed | MLOps UI → Admin → MLOps → Runtimes | Only trusted images; unused runtimes disabled/deprecated |
| Production deployments monitored | MLOps UI → Deployments → Monitoring tab | Monitoring enabled for production deployments |
| Stale members removed | Admin Center → Member Management | No accounts for departed personnel |
| Custom groups aligned with org | Admin Center → Custom Groups | Groups reflect organizational structure |
10. Machine-readable configuration format
10.1 API-based configuration export
Export your current tenant configuration programmatically using the MLOps APIs. The APIs return Protocol Buffer (protobuf) messages, which you can serialize to JSON for machine-readable comparison.
Export workspace and RBAC configuration:
import json
# Export workspaces
workspaces = [
{"name": ws.name, "uid": ws.uid, "creator": ws.creator}
for ws in client.workspaces.list()
]
# Export role bindings
role_bindings = [
{"subject": rb.subject, "role": rb.role, "resource": rb.resource}
for rb in client._backend.authz.role_binding.list_role_bindings()
]
# Export deployment security
deployment_security = []
for ws in client.workspaces.list():
for dep in ws.deployments.list():
deployment_security.append({
"workspace": ws.name,
"deployment": dep.name,
"security_options": str(dep.security_options),
})
config = {
"workspaces": workspaces,
"role_bindings": role_bindings,
"deployment_security": deployment_security,
}
with open("mlops-tenant-config.json", "w") as f:
json.dump(config, f, indent=2)
10.2 Baseline comparison
Compare the exported configuration against this guidance:
- Verify all deployments have PBKDF2 or OIDC security (Section 6.1).
- Verify role bindings follow least-privilege (Section 6.2).
- Verify admin count is minimized (Section 6.3).
- Verify custom runtimes use trusted images (Section 6.4).
11. API-based settings management
11.1 Available APIs
H2O MLOps provides the following APIs for agency administrators to manage security-relevant settings:
| API service | Key operations | Security relevance |
|---|---|---|
| DeploymentService (gRPC/Connect) | CreateDeployment, UpdateDeployment, DeleteDeployment, ListDeployments, PauseDeployment, ResumeDeployment | Manages deployment lifecycle including per-deployment scoring security (TL-01, TL-02) |
| ConfigService (gRPC/Connect) | GetDefaultSecurityOptionType, ListSecurityOptionTypes, GetMonitoringConfig, DiscoverDeploymentMaxReplicas | Read-only platform configuration discovery |
| RuntimeService (gRPC/Connect) | CreateRuntime, UpdateRuntime, DeleteRuntime, EnableRuntime, DisableRuntime, DeprecateRuntime | Custom runtime lifecycle management (TL-08) |
| WorkspaceService (gRPC/Connect) | CreateWorkspace, UpdateWorkspace, DeleteWorkspace, ListWorkspaces, ArchiveWorkspace | Workspace lifecycle management (TL-03) |
| RoleService (gRPC/Connect) | CreateRole, UpdateRole, DeleteRole, ListRoles, AddActionStatements, RemoveActionStatements | Custom role definition (Section 5.2.3) |
| RoleBindingService (gRPC/Connect) | CreateRoleBinding, DeleteRoleBinding, ListRoleBindings, BatchCreateRoleBindings, BatchDeleteRoleBindings | Access control management (TL-04) |
| PermissionPresetService (gRPC/Connect) | CreatePermissionPreset, UpdatePermissionPreset, DeletePermissionPreset, ListPermissionPresets | Reusable permission templates (Section 5.2.4) |
| StorageService (gRPC/Connect) | DeleteExperiment, DeleteModel, DeleteDataset, RecoverDeletedExperiment | Data lifecycle management (Section 7.3) |
| EndpointService (gRPC/Connect) | CreateEndpoint, UpdateEndpoint, DeleteEndpoint, ListEndpoints | Scoring endpoint management |
| MonitoringService (gRPC/Connect) | GetModelHealthMetrics, GetModelDriftMetrics, GetModelOperationalSummaryMetrics | Read-only monitoring data access |
11.2 Python Client
The H2O MLOps Python Client (h2o_mlops) provides a high-level SDK wrapping these gRPC APIs:
import h2o_mlops
client = h2o_mlops.Client(
gateway_url="https://mlops-api.example.com",
token_provider=token_provider,
verify_ssl=True # Default: True (uses certifi CA bundle)
)
# Workspace management
workspace = client.workspaces.create(name="production")
workspaces = client.workspaces.list()
# Deployment management
deployments = workspace.deployments.list()
deployment = workspace.deployments.get(name="my-model")
deployment.update(security_options={"passphrase": "...", "hash_algorithm": "PBKDF2"})
deployment.pause()
deployment.resume()
deployment.delete()
# Runtime management
runtimes = workspace.runtimes.list()
runtime = workspace.runtimes.create(name="custom-runtime", ...)
runtime.disable()
runtime.deprecate()
# Endpoint management
endpoints = workspace.endpoints.list()
endpoint = workspace.endpoints.create(name="my-endpoint", ...)
# Monitoring
health = deployment.monitoring.baseline_aggregates
Configure custom CA certificates via:
ssl_cacertparameter on the Client constructorMLOPS_AUTH_CA_FILE_OVERRIDEenvironment variable
11.3 Admin Center UI
The Admin Center provides a web-based interface for administrative operations:
| Page | Operations | Security relevance |
|---|---|---|
| Member Management | Add/remove members, promote/demote admin, bulk import | AC-2: User account management |
| Custom Groups | Create/manage groups, manage membership | AC-2: Group-based access management |
| MLOps Deployments | View all deployments, security status, resource specs | Deployment security visibility |
| MLOps Runtimes | View/manage runtimes, runtime images | CM-7: Runtime lifecycle management |
| Manage Workspaces | Create/edit/delete/archive workspaces | AC-4: Workspace isolation management |
| User Login Analytics | View login statistics, heatmaps, user activity | AU-2: Authentication activity monitoring |
| App Events / Instance Events | Monitor application and instance events | AU-2: Event monitoring |
Next steps
- Create a deployment to apply scoring endpoint security (TL-01, TL-02).
- Python Client SDK for programmatic access to all configuration APIs.
- Workspaces for workspace structure and management.
- Submit and view feedback for this page
- Send feedback about H2O MLOps to cloud-feedback@h2o.ai