S3 Object Store Server User Compliance in ONTAP
Applies to
- NetApp ONTAP 9.17.1P3 and later
- AFF-A250 (and all ONTAP-based S3 Object Store Server deployments)
- S3 Object Store Server feature in ONTAP
- User management and compliance/security configuration
Answer
Questions from Customer:
We recently created an S3 Object Store Server in our ONTAP environment, and our compliance team has requested clarification on several configuration and security items. Specifically, for user management within the S3 Object Store Server setup, they would like to know:
- How can we obtain a list of all users?
- How can we enforce password complexity requirements, including:
- Minimum password length
- Minimum number of characters
- Minimum number of digits
- Minimum number of uppercase letters
- Minimum number of lowercase letters
- How can we enforce password expiration every 365 days?
- How can we configure account lockout after a specified number of unsuccessful login attempts?
- How can we enforce any additional required security controls?
- What is the purpose of the root user, and can root login access (ssh, https, etc.) be disabled like vsadmin account lock in Vserver?
- If these features are not available, please confirm that they are not available from the product.
Answers Provided:
1. How can we obtain a list of all users?
- For local S3 users:
Use the ONTAP CLI command:object-store-server user show
This will list all local S3 users configured on the object store server. - For AD or LDAP users:
User management is handled externally in Active Directory or LDAP. You would need to query those systems.
2. Password Complexity Requirements (length, characters, digits, etc.):
- Local S3 users do not use passwords. Authentication is handled via access and secret keys (similar to AWS S3).
- Therefore, password complexity requirements do not apply to local S3 users.
- For AD or LDAP users:
Password complexity is managed by your AD/LDAP policies outside of ONTAP.
References:
3. Password Expiration (every 365 days):
-
For local S3 users, you can configure access/secret keys to expire during user creation or key generation.
-
To regenerate keys or set expiration:
-
For AD/LDAP users, password expiration is managed via AD/LDAP policies.
4. Account Lockout after Unsuccessful Login Attempts:
- Not possible for local S3 users.
There is no feature in ONTAP S3 implementation to lock out accounts after failed login attempts. - For AD/LDAP users, account lockout is managed via AD/LDAP policies.
5. Additional Security Controls:
- For local users, security controls are limited to:
- Key expiration/regeneration
- Access control via S3 groups and bucket policies (not password controls)
- Create/Modify Groups
- Create/Modify Bucket Policy Statements
- For AD/LDAP users, additional controls are managed externally.
6. Root User Purpose and Access Control:
- The root user is created by default when the S3 object store server is created, similar to root on a Linux system. It acts as a default admin role and is not needed for standard user access.
- By default, the root user does not have access/secret keys generated—these must be manually created if needed.
- NetApp best practice:
Do not use the root user for client/application access. Any client using root’s access/secret key has full access to all buckets and objects. - The root user cannot be disabled for S3, but does not provide SSH/HTTPS access like vsadmin.
It is strictly for S3 object store server administrative actions. - Reference:
Create the ONTAP S3 object store server
7. Feature Availability Confirmation:
- Password complexity, expiration, and account lockout features are not available for local S3 users in ONTAP.
- These features are only available for AD/LDAP users and must be managed externally.
Summary Table
| Feature/Requirement: | Local S3 Users | AD/LDAP Users |
| Password Complexity | Not applicable | Managed in AD/LDAP |
| Password Expiration | Key expiration only | Managed in AD/LDAP |
| Account Lockout | Not applicable | Managed in AD/LDAP |
| Additional Security Controls | Groups, bucket policies, key expiration | Managed in AD/LDAP |
| Root User Access | Admin only, no SSH/HTTPS, keys must be manually generated | N/A |