User

What is a User in cloud hosting?

A user is an individual account that can authenticate with a cloud platform and interact with resources. Each user has a unique identity, credentials for authentication, and permissions that define what actions they can perform. In OpenStack-based cloud platforms, users are managed by the identity service and can belong to one or more projects.

Users represent both human operators who log into dashboards and command-line tools, and service accounts that applications use to access cloud APIs programmatically. The distinction matters because human users typically authenticate with passwords or multi-factor authentication, while service accounts use API keys or application credentials.

Related Terms

• Project: An isolated container for cloud resources that users are assigned to, such as a development team's workspace containing their instances, networks, and storage volumes.
• Keystone: The OpenStack identity service that authenticates users and manages their credentials, such as verifying passwords and issuing access tokens for API requests.
• Identity Management: The overall system for creating, managing, and authenticating user identities, such as defining who can log in and what permissions they receive.
• SSH Key Pairs: A cryptographic authentication method that users configure for secure access to instances, such as uploading a public key that allows passwordless login to virtual machines.
• Role: A named set of permissions that defines what actions a user can perform, such as "admin" for full control or "member" for standard operations within a project.

Why Users Exist

Without individual user accounts, everyone would share the same credentials to access cloud resources. This creates several problems.

First, there would be no accountability. When something breaks or gets deleted, you cannot determine who made the change. Audit logs would show the same identity for every action, making troubleshooting and compliance impossible.

Second, access control would be all-or-nothing. You could not give a junior developer read-only access while allowing senior engineers to modify production systems. Everyone with the shared credentials would have identical permissions.

Third, credential management becomes dangerous. When an employee leaves, you cannot revoke their individual access. You would need to change the shared password and distribute the new one to everyone else, hoping no unauthorized copies remain.

Users solve these problems by creating distinct identities. Each person or application authenticates separately. The platform tracks every action to the specific user who performed it. Administrators assign different roles and permissions to different users. Revoking access means disabling one account without affecting others.

What Do Users Actually Do?

• Authenticate to the platform by providing credentials such as a username and password, API key, or federated identity token
• Receive an access token after successful authentication that proves their identity for subsequent API requests
• Access resources within assigned projects based on the roles granted to them in each project
• Perform actions such as creating instances, managing networks, uploading images, or viewing billing data according to their permissions
• Manage their own credentials by changing passwords, rotating API keys, or configuring multi-factor authentication
• Generate application credentials that allow scripts and applications to authenticate on their behalf with limited scope

When Would I Use a User?

You create a user account for each person who needs to access your cloud platform. This includes developers who deploy applications, operations staff who monitor and maintain infrastructure, and administrators who manage the platform itself.

You also create service accounts (a type of user) for applications that need to interact with cloud APIs. A deployment pipeline that provisions infrastructure needs credentials to authenticate. A monitoring system that collects metrics from instances needs API access. These automated systems use dedicated user accounts rather than human credentials.

When onboarding a new team member, you create their user account, assign them to the appropriate projects, and grant roles that match their responsibilities. A junior developer might get read access to production and full access to development. A security auditor might get read-only access across all projects for compliance reviews.

When Would I NOT Use a User?

You would not create individual user accounts if your organization uses federated identity. Instead of managing users directly in the cloud platform, you connect to an external identity provider like LDAP, Active Directory, or SAML. Users authenticate through the external system, and the cloud platform accepts their federated credentials. This avoids maintaining duplicate user databases.

You would not create a new user for every script or automation. If the same team owns multiple automation tools, those tools can share a service account with appropriate permissions. Creating too many service accounts increases management overhead without improving security.

You would not give a user direct access when they only need temporary credentials. If a contractor needs one-time access to debug an issue, consider using time-limited tokens or temporary project membership rather than creating a permanent user account.

Real-World Example

Company A runs an e-commerce platform on an OpenStack-based cloud. They have three environments: production, staging, and development. Each environment exists as a separate project.

The operations team has five members. Each person has their own user account. In the production project, they are assigned the "operator" role, which allows them to manage instances and view logs but not modify network configurations or security groups. In the staging project, they have the "admin" role with full permissions for testing changes. The development project uses the same "admin" role.

The development team has fifteen members. Their user accounts have "member" role in development for deploying and testing code. They have read-only "observer" role in staging to view logs and debug issues. They have no access to production at all.

The CI/CD pipeline uses a service account with "member" role in all three projects. It can deploy code and manage instances but cannot change network configurations or user permissions.

When a developer leaves the company, the administrator disables their user account. Their access to all projects is immediately revoked. The CI/CD pipeline and other team members continue working without interruption. Audit logs show exactly what the departed developer accessed and modified during their tenure.

Frequently Asked Questions

Can one user belong to multiple projects? Yes. A user can be a member of many projects simultaneously with different roles in each. For example, a user might be an admin in the development project but only a viewer in production. When working in the platform, users switch between projects to access different sets of resources.

What happens when a user is deleted? Resources the user created remain in their respective projects. Those resources are owned by the project, not the user personally. However, application credentials and API keys issued to that user stop working immediately. Any running processes using those credentials will fail to authenticate on their next API call. Before deleting a user, transfer ownership of any critical automation to another account.

What is the difference between a user and a service account? Both are user accounts in the technical sense. The distinction is how they authenticate and what they represent. Human users log in with passwords through dashboards or CLI tools. Service accounts authenticate with API keys or application credentials from automated scripts. Some platforms enforce this distinction with separate account types, while others treat all users identically. The best practice is to create dedicated accounts for automation so you can audit their actions separately from human activity.

How do roles affect what a user can do? Roles are collections of permissions. When you assign a role to a user in a project, you grant all permissions included in that role. Common roles include admin (full control), member (create and manage resources), and reader (view-only access). The exact permissions depend on how your cloud platform is configured. Users can have different roles in different projects, so the same person might be an admin in one project and a reader in another.

Can users share credentials? Technically possible but strongly discouraged. Shared credentials eliminate accountability because you cannot determine who performed an action. They also create security risks when someone who knows the password leaves the organization. Every person and every automated system should have their own user account. If you currently share credentials, create individual accounts and transfer access before disabling the shared one.

Summary

• A user is an individual account that authenticates with a cloud platform using credentials like passwords, API keys, or federated identity tokens.
• Each user has a unique identity that the platform tracks for audit logging, access control, and credential management.
• Users belong to projects and receive roles that define their permissions for creating and managing cloud resources.
• Human users log in through dashboards and CLI tools, while service accounts provide credentials for automated scripts and applications.
• Individual user accounts enable accountability, granular access control, and safe credential revocation when someone leaves the organization.