SSH Key Management in PowerVS: Account vs Workspace Scope for Enhanced Multi-Tenant Security
Author: Suvendu Ranjan Nayak (Suvendu.Ranjan.Nayak1@ibm.com)
Guidance & Contribution: Sreevidhya Nair (sreevina@in.ibm.com)
Introduction:
PowerVS supports workspace-scoped SSH keys, allowing Managed Service Providers (MSPs) and customers to control the visibility of SSH keys — either across the entire account or within a specific workspace. This capability strengthens security and privacy while remaining fully compatible with existing deployments.
Why this matters:
In PowerVS, SSH keys can exist at either the account level or the workspace level. Traditionally, keys were stored at the account (tenant) level, making them visible across all workspaces in that account. For MSPs managing multiple customers or environments, that visibility could lead to unnecessary exposure of credentials.
Workspace-scoped keys solve that by letting you scope a key to a single workspace (or keep it shared at the account level) — improving isolation between environments and ensuring credentials stay where they’re needed.
This applies to both PowerVS Public and Private environments.
Key advantages:
-
Improved isolation and control: Keeps customer environments and resources securely separated, ideal for MSPs and enterprises.
-
Enhanced privacy and security: Keys can be limited to individual workspaces.
-
Seamless compatibility: Existing account-level keys remain operational without any changes to their functionality.
How it works:
PowerVS now supports management of both workspace-scoped and account-scoped keys through updated APIs. Each workspace key has a unique ID, while legacy (account-level) keys remain available and supported.
-
The instance-deploy API still supports name-based key lookup for backward compatibility, but key IDs are recommended going forward.
-
UI, CLI and Terraform interfaces use the new APIs. The UI likely will not visually distinguish between legacy and new account level keys (users will see names), but the underlying APIs will.
What users (MSPs / customers) will notice:
-
No existing keys are lost — legacy keys remain fully usable.
-
Users can create:
-
Account-scoped keys (visible to all workspaces), or
-
Workspace-scoped keys (visible only in one workspace).
-
New keys support descriptions; older ones may display a blank description.
-
Legacy keys are treated as shared resources, with the primary workspace parameter set to true across all workspaces, as they can be modified or removed by any workspace.
-
Update and delete permissions depend on key ownership — Workspaces that do not own a key cannot modify or delete keys associated with another workspace.
-
Name-to-ID mapping is retained to ensure compatibility with existing scripts and Terraform configurations.
UI / CLI behavior:
-
PowerVS UI displays keys by name using the new APIs. If legacy and workspace keys share the same name, multiple entries may be displayed.
-
Power-IaaS CLI also uses the updated APIs, automatically performing name-to-ID resolution.
-
During VSI deployment, PowerVS checks both legacy and workspace key repositories — preferring workspace-scoped keys when available.
Use cases:
1.1 GUI-Based Method for SSH Key Creation.
The 'Create SSH Key' option is available on the SSH Keys page. It allows users to create SSH keys with either account-level or workspace-specific scope. Users can set the key name, choose the access level (account or workspace), add a description, and provide the required SSH key details.
1.2 The newly created SSH keys are displayed as follows.
2.1 API Method for Creating an SSH Key.
curl -X POST https://us-east.power-iaas.cloud.ibm.com/v1/sshkeys/post -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -H "CRN: $CRN"
-d '{
"description":"Description for the ssh-key",
"name":"sshkey-name",
"sshKey":"ssh-rsa-key",
"visibility":"account"
}'
2.2 API Method for Listing Newly Created SSH Keys.
curl -X GET https://us-east.power-iaas.cloud.ibm.com/v1/sshkeys -H "Authorization: Bearer $TOKEN" -H "CRN: $CRN" -H "Content-Type: application/json"
3.1 CLI Command for Creating an SSH Key.
ibmcloud pi ssh-key create KEY_NAME --key KEY [--description DESCRIPTION] [--visibility ("account" | "workspace")]
3.2 CLI Command for Listing Newly Created SSH Keys.
ibmcloud pi ssh ls
3.3 Additional CLI Options for Managing SSH Keys
Known limitations:
Security considerations:
Workspace-scoped keys align PowerVS with IBM Cloud tenancy best practices — ensuring that resources belong to specific workspaces rather than being visible across the entire account. This minimizes cross-workspace access risks and improves overall data protection.
FAQ:
Q: Will I lose keys during the transition?
A: No. All keys remain accessible. Legacy keys continue to work through existing APIs, while the new APIs can read both legacy and workspace key databases.
Q: Can I make an existing account key visible only to one workspace?
A: Migrated legacy keys retain shared/account visibility. To limit visibility, recreate the key within a specific workspace or use a visibility-change option if available in future tooling.
Q: Can a workspace share the same key across multiple workspaces?
A: Direct cross-workspace sharing is not currently supported, but the same key can be manually created in multiple workspaces if needed.
Final notes:
Workspace-scoped SSH keys are a practical enhancement that brings PowerVS key management in line with workspace boundaries and IBM Cloud security principles. MSPs and enterprises can use this flexibility to tighten access controls, reduce accidental key exposure, and update automation to use key IDs for long-term stability.
Reference:
https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-creating-ssh-key
https://cloud.ibm.com/apidocs/power-cloud#pcloud-tenants-sshkeys-getall
https://cloud.ibm.com/apidocs/power-cloud#v1-sshkeys-getall