Self-Service Portal Design (Catalog + Projects)

Design catalog item taxonomy:

Key sizes (vCPU/RAM in GB/Storage in GB where listed):

• S: 2 vCPU, 4-8 GB RAM
• M: 4 vCPU, 8-32 GB RAM
• L: 8 vCPU, 16-64 GB RAM
• XL: 16 vCPU, 64 GB RAM (requires approval)

Design a detailed cloud template (Linux App Server example):

Aria Automation Cloud Template (YAML-based):

name: Linux App Server
version: 2.1
inputs:
  size:
    type: string
    enum: [Small, Medium, Large]
    default: Medium
  environment:
    type: string
    enum: [Production, Development]
  application_name:
    type: string
    pattern: '^[a-z0-9-]{3,20}$'
  owner_email:
    type: string
  lease_days:
    type: integer
    minimum: 1
    maximum: 365
    default: 90

resources:
  app_server:
    type: Cloud.vSphere.Machine
    properties:
      name: '${input.application_name}-app'
      image: rhel9-hardened-golden
      flavor: '${input.size}'
      constraints:
        - tag: 'placement:${input.environment == "Production" ? "tier2" : "dev"}'
      networks:
        - network: '${resource.app_network.id}'
      storage:
        bootDiskCapacityInGB: 80
      security:
        vtpm: true
        secureboot: true
      customizationSpec: linux-app-customization
      tags:
        - key: tier
          value: app
        - key: env
          value: '${input.environment == "Production" ? "prod" : "dev"}'
        - key: owner
          value: '${input.owner_email}'
        - key: lease_expiry
          value: '${now() + duration(input.lease_days, "days")}'

  app_network:
    type: Cloud.NSX.Network
    properties:
      networkType: existing
      constraints:
        - tag: 'segment:app-${input.environment == "Production" ? "prod" : "dev"}'

Governance constraints embedded:

• Image: Hardened golden image only (no custom ISOs)
• vTPM: Always enabled (non-negotiable for production)
• Tags: Automatically applied for DFW group membership
• Lease: Maximum 365 days; expiry triggers decommission workflow
• Naming: Regex-enforced naming convention
• Placement: Constraint tags control which cloud zone

Design governance policies:

1. Lease management:

• All VMs have a lease (default: 90 days, max: 365 days)
• 14-day warning before lease expiry
• 7-day final warning
• At expiry: VM powered off (not deleted) — owner has 30 days to renew
• After 30 days: VM deleted (with 7-day trash recovery)
• Exception: Production Tier-1 VMs can have indefinite lease with annual review

2. Approval policies:

• Self-service (no approval): Small/Medium VMs in dev cloud zones
• Manager approval: Large/XL VMs in any cloud zone
• Infrastructure team approval: Any VM in Tier-1 cloud zone
• Security team approval: VMs requesting external network access

   - Approval via: Aria Automation approval workflow → integrates with ServiceNow

3. Day-2 actions available to users:

• Power on/off/restart
• Resize (within allowed sizes — cannot exceed project quota)
• Add disk (up to storage quota)
• Snapshot (max 3 snapshots, max 72 hours — auto-delete after)
• Reconfigure (add NIC, change network — requires approval if crossing security zones)
• Delete (immediate, no approval needed — user's own resource)

4. Prohibited actions (even for project admins):

• Change storage policy (must match catalog item governance)
• Disable vTPM or encryption
• Move VM to different project
• Connect to unmanaged network (bypass NSX)

Design monitoring and chargeback:

1. Resource metering:

• Aria Operations tracks: vCPU hours, GB-RAM hours, GB-Storage used, IOPS consumed
• Metric granularity: Hourly samples, daily aggregation, monthly billing report

2. Chargeback model:

3. Showback dashboard (per project):

• Current month cost
• Cost trend (month-over-month)
• Top 10 most expensive VMs

   - Idle VM detection (CPU <5% for 7 consecutive days → flag for decommission)

• Orphaned resources (disks without VMs, unused networks)

4. Cost optimization recommendations:

   - Right-sizing: VMs consistently using <25% of allocated vCPU → suggest downsize
   - Powered-off VMs: VMs powered off for >30 days → suggest deletion
   - Dev/test scheduling: Auto power-off dev VMs at 8 PM, power-on at 7 AM → 50% cost savings

Design role hierarchy:

Least-privilege principle:

• Cloud Consumers cannot access infrastructure directly (no vCenter, no NSX)
• Project Admins can manage their project but cannot affect other projects
• Cloud Admins can design templates but cannot bypass security policies
• Only Infrastructure Admins can modify SDDC Manager and management domain

Design identity source integration:

1. Active Directory integration:

• vCenter SSO: AD/LDAPS identity source added
• Aria Automation: AD/LDAPS for user authentication
• NSX Manager: AD/LDAPS for admin access
• SDDC Manager: Local admin + AD for operator access

2. AD group mapping:

3. MFA requirement:

• All admin roles (Cloud Admin, Infra Admin, Security Admin): MFA required
• Cloud Consumers: MFA optional (depends on organization policy)
• Implementation: AD FS with MFA provider (Azure MFA, Duo, RSA)

4. Service accounts:

   - Aria Automation → vCenter: Dedicated service account (vcf-aria-svc@domain.com)
   - Aria Automation → NSX: Dedicated service account (vcf-aria-nsx-svc@domain.com)

• Permissions: Minimum required for provisioning operations
• Password rotation: 90-day automated rotation via secrets manager

Design access control for sensitive operations:

1. Emergency access (break-glass):

• Scenario: AD is down, normal authentication unavailable
• Procedure:

a. Use local admin accounts (vcfadmin@vsphere.local for vCenter)
b. Credentials stored in sealed envelope in physical safe
c. Every break-glass access triggers audit alert
d. Post-incident: Change all local admin passwords

2. Privileged access management:

• Admin sessions: Maximum 8-hour session duration, auto-logout
• API access: Token-based with 1-hour expiry, scope-limited
• SSH to ESXi hosts: Disabled by default; enabled per-host via lockdown mode exception
• ESXi Shell: Timeout after 900 seconds of inactivity

3. Audit trail:

• All authentication events logged to Aria Operations for Logs
• vCenter tasks and events: Retained for 365 days
• NSX audit log: All DFW changes logged with user identity
• SDDC Manager audit: All lifecycle operations logged
• Report: Monthly access review report for SOC 2 evidence

Create design decision D-012 — Self-Service Access Model:

Decision: Aria Automation with project-based isolation and catalog-driven provisioning

Alternatives:
A) Direct vCenter access for all users:

• Pro: Familiar interface, full flexibility
• Con: No governance, no quotas, no audit trail for provisioning decisions
• Rejected: Cannot enforce golden image usage, VM tagging, or lease management

B) ServiceNow only (ITSM ticket for all provisioning):

• Pro: Full change management for every VM
• Con: 3-5 day lead time for VM provisioning; developers bypass with shadow IT
• Rejected: Unacceptable velocity for development teams

C) Aria Automation (Catalog-based self-service):

• Pro: Developer velocity (minutes to deploy), governance embedded in templates, quota enforcement
• Con: Additional Aria license cost, template maintenance overhead
• SELECTED: Balances speed with control

Justification: Catalog-driven model reduces VM provisioning from 3-5 days to 5-10 minutes while maintaining governance controls (golden images, vTPM, tags, leases, quotas).

Design quota monitoring alerts:

Escalation:

• Warning: Informational, no action required for 30 days
• Critical: Must acknowledge within 4 hours; action plan within 24 hours
• Exceeded: Immediate — provisioning is blocked

Design idle resource detection:

1. Idle VM criteria:

• CPU utilization <5% average for 14 consecutive days
• Network traffic <1 Mbps for 14 consecutive days
• No console or SSH sessions for 14 days
• Exceptions: Monitoring agents, backup targets, license servers (tag-based exclusion)

2. Idle resource workflow:

   Day 1: VM identified as idle → automated tag applied (lifecycle:idle)
   Day 1: Email notification to VM owner: 'Your VM appears idle'
   Day 14: If still idle → second notification: 'VM will be powered off in 7 days'
   Day 21: VM automatically powered off (not deleted)
   Day 51: If still powered off → notification: 'VM will be deleted in 30 days'
   Day 81: VM deleted → storage reclaimed

3. Orphaned resource detection:

• Disks without VMs (detached VMDKs)
• NSX segments with 0 connected VMs
• Snapshots older than 72 hours
• Report: Weekly orphaned resource report to project admins

Design quota increase workflow:

1. Request:

• User: Submits quota increase request via Aria Automation custom form
• Fields: Project, resource type, requested increase, business justification

2. Approval chain:

• Level 1: Project owner reviews business justification (auto-approve if <10% increase)
• Level 2: Cloud admin verifies infrastructure capacity
• Level 3: Finance approval if chargeback impact >$X/month

3. Fulfillment:

• Approved: Cloud admin updates project quota in Aria Automation
• Denied: Feedback provided with alternative options (right-size existing VMs, decommission idle)
• SLA: 2 business days for standard requests, 4 hours for emergency

4. Capacity-triggered procurement:

   - When cluster utilization consistently >75% for 30 days → trigger procurement workflow

• Procurement lead time: 8-12 weeks for new hosts
• Bridge solution: Enable HCI Mesh from underutilized cluster if available
• Decision point: Add hosts to existing cluster vs create new workload domain

Design self-service portal operational summary:

1. Architecture diagram:

[Users] → [Aria Automation Portal]
              ↓
    [Catalog Items / Templates]
              ↓
    [Approval Policies]──→ [ServiceNow Integration]
              ↓
    [Cloud Zones + Placement]
              ↓
    [vCenter API]──→ [VM Provisioning]
    [NSX API]───→ [Network + DFW Tags]
    [vSAN]─────→ [Storage Policy Applied]
              ↓
    [Aria Operations]──→ [Monitoring + Quota Tracking]
              ↓
    [Chargeback Reports]──→ [Finance Dashboard]

2. KPIs:

• Provisioning time: <10 minutes (target) from request to VM ready
• Quota compliance: 100% — no VM exists outside a project
• Idle VM ratio: <5% of total VMs (measured monthly)
• Catalog adoption: >90% of VMs deployed via catalog (not manual)

3. Continuous improvement:

• Monthly: Review catalog item usage — retire unused items, add new ones
• Quarterly: Review quota allocations vs consumption — right-size quotas
• Annual: User satisfaction survey — gather feedback on catalog items and approval speed