Users of ECS can be management users, object users, or both, as shown in Figure 10. Management users have access to the ECS through its web portal and through the management API. Object users have access to the ECS object interfaces for S3, OpenStack Swift, Atmos, Centera CAS, HDFS, and NFS. An object user uses a native object interface (for example, the standard S3 API) to perform data access operations such as reading, writing, or listing objects in buckets. They can also create or delete buckets. If a user requires access to both the ECS portal and the ECS object interfaces, that user must be created as both a management user and an object user. ECS does not know, for example, that a single individual named Bob is both a management user and also an object user. To ECS, management and object users are not correlated.
Figure 10. Types of ECS users
- When there is a large group of users to be given access to the object store, leverage existing Active Directory or LDAP infrastructure.
- A common pitfall to make names unique and consistent with Active Directory names is to create local accounts using a domain style. This implies that Active Directory or LDAP performs authentication. However, in ECS, authentication is done using secret keys; thus, to avoid confusion, do not use domain-style names as local accounts that are not part of any domain.
- The user scope setting must be made before the first object user is created. That is, once the first object user is created in a VDC, the user scope setting cannot be changed. The default user scope setting is GLOBAL. If you intend to use ECS in a multitenant configuration and want to ensure that tenants are not prevented from using names that are in use in another namespace, change this default configuration to NAMESPACE.
- Management users, whether local or domain based, are not replicated across geo-federated VDCs. This means that all administrators except namespace administrator must be created at each VDC that requires the account or role. Domain-based namespace administrator accounts are excluded in this caveat because namespaces are global constructs and, as such, their associated administrators are also global.
- Local management accounts are not replicated across sites, so a local user who is a namespace administrator can only log in at the VDC at which the management user account was created. If you want the same username to exist at another VDC, the user must be created at the other VDC. Because the accounts are different, changes to a same-named account at one VDC, such as a password change, are not propagated to the account with the same name at the other VDC.
- Namespace administrator can only be the administrator of a single namespace.