A Comprehensive Guide to IAM in Object Storage
In this article, learn about identity access management, service IDs, service credentials, and their role in securing access to object storage on the cloud.
Join the DZone community and get the full member experience.
Join For FreeIdentity and access management (IAM), service IDs, and service credentials are crucial components in securing and managing access to object storage services across various cloud platforms. These elements work together to provide a robust framework for controlling who can access data stored in the cloud and what actions they can perform.
In the previous article, you were introduced to the top tools for object storage and data management. In this article, you will learn how to restrict access (read-only) to the object storage bucket through custom roles, access groups, and service credentials.
Identity and Access Management (IAM)
IAM is a comprehensive system for managing access to cloud resources, including object storage. It allows organizations to control who has access to what resources and what actions they can perform on those resources. IAM is built on several key concepts:
- Users – Individual accounts that represent people or applications accessing cloud resources
- Roles – Collections of permissions that define what actions can be performed on resources
- Policies – Rules that associate users or groups with roles, determining their access levels
- Resources – The cloud assets being protected, such as buckets and objects in object storage
In the context of object storage, IAM enables administrators to:
- Grant read, write, or delete permissions on specific buckets or objects
- Implement the principle of least privilege by assigning only necessary permissions
- Manage access across multiple teams or projects within an organization
- Enforce compliance requirements by controlling data access
IAM systems typically offer predefined roles that cover common use cases, such as "Object Creator" or "Object Viewer." These roles can be assigned to users or groups to quickly set up appropriate access levels. For more granular control, custom roles can often be created to meet specific organizational needs.
Service IDs
Service IDs are a concept closely related to IAM, particularly useful in the context of object storage. A service ID is a unique identifier that represents an application or service, rather than an individual user. Service IDs are essential for scenarios where:
- Applications need programmatic access to object storage
- Automated processes require authentication to perform tasks
- Long-lived access is needed without tying it to a specific user account
Service IDs can be assigned IAM roles and policies, just like user accounts. This allows for precise control over what actions an application or service can perform on object storage resources. For example, a backup application might be given a service ID with permissions to read and write to specific buckets, but not to delete objects or modify bucket settings.
Key advantages of using service IDs include:
- Separation of concerns. Access to applications is managed separately from user access.
- Auditability. Actions performed using service IDs can be tracked and audited.
- Lifecycle management. Service IDs can be created, modified, or revoked without affecting user accounts.
- Scalability. Multiple applications can use the same service ID if they require identical permissions.
Service Credentials
Service credentials are the authentication details associated with service IDs. They provide the necessary information for applications to securely connect to and interact with object storage services. Service credentials typically include:
- API keys – Unique identifiers used for authentication
- Secret keys – Confidential strings used in combination with API keys to verify identity
- Endpoints – URLs specifying where to send API requests
- Resource identifiers – Unique strings identifying specific object storage instances or resources
Service credentials are crucial for enabling secure programmatic access to object storage. They allow applications to authenticate and perform actions without requiring interactive login processes. When working with service credentials, it's important to:
- Securely store and manage these credentials to prevent unauthorized access
- Implement credential rotation practices to periodically update access keys
- Use environment variables or secure secret management systems to inject credentials into applications
HMAC Credentials
Hash-based message authentication code (HMAC) credentials are a specific type of authentication mechanism used in object storage systems. HMAC credentials consist of an access key ID and a secret access key.
They play a crucial role in securing object storage by providing a way to sign API requests and ensuring the integrity and authenticity of the requests. HMAC credentials are particularly important for maintaining compatibility with S3-style APIs and tools across different cloud providers.
Use Case: Read-Only Access to the Object Storage Bucket
Let's bring everything together. One use case that cumulates IAM (custom roles), service credentials, and service ID is to provide read-only access to a specific object storage bucket. This restricted access will be applied to the access via UI and tools like CyberDuck or S3browser.
Create a Custom Role
Follow the instructions here to create a custom role with the below actions:
- cloud-object-storage.account.get_account_buckets – Read access to the buckets in a cloud object storage service instance.
- resource-controller.credential.retrieve_all – Read access to the service credentials.
- cloud-object-storage.object.get_tagging – Read access to the object storage tags
Create an Access Group
Follow the instructions to create an access group with policies restricting access to the specific object storage service and bucket-level access to the individual users with the custom role that you created.
Remember to restrict the resource to a bucket and service access to Content Reader
and Object Reader
for read-only access.
Create a Service Credential With a Service ID and HMAC-Enabled
1. Follow the instructions to create a service credential with ServiceID. Specify None
to assign no role to the new credential as we will manage access by associating a service ID with the service credential. Create object storage service credentials with HMAC enabled.
HMAC credentials include the access key and secret key required to connect from external tools like MINio, Cyberduck, S3Browser. Check my article on how to use these tools with HMAC credentials.
2. Assign the access group that is created above to the created ServiceID.
As mentioned in the article here, using the HMAC credentials will now restrict access to read-only on the specific object storage bucket.
Cloud Providers and Object Storage
Several major cloud providers offer object storage services, each with its own implementation of IAM, service IDs, and credentials:
-
Amazon Web Services (AWS) S3.
- Uses AWS identity and access management (IAM)
- Offers IAM users and roles
- Provides access keys and secret access keys for authentication
-
Google Cloud Storage.
- Integrates with Google Cloud IAM
- Supports service accounts for application-level access
- Offers HMAC keys for interoperability
-
Microsoft Azure Blob Storage.
- Uses Azure Active Directory (Azure AD) for identity management
- Provides managed identities for Azure resources
- Offers shared access signatures (SAS) for granular, time-limited access
-
IBM Cloud Object Storage.
- Implements IBM Cloud IAM
- Supports service IDs for application authentication
- Provides HMAC credentials for S3 API compatibility
-
Oracle Cloud Infrastructure (OCI) Object Storage.
- Uses OCI IAM for access management
- Offers instance principals for compute instances to access object storage
- Supports customer-managed keys for enhanced security
These providers generally follow similar principles in their IAM and credential management systems, but with variations in terminology and specific features. For example, what IBM calls a "Service ID" might be referred to as a "Service Account" in Google Cloud or a "Service Principal" in Azure.
Best Practices for IAM and Credentials in Object Storage
To effectively manage access and security in object storage using IAM, Service IDs, and Service Credentials, consider the following best practices:
- Implement the principle of least privilege. Grant only the minimum necessary permissions to users and service IDs.
- Use service IDs for application access. Avoid using personal user credentials for application authentication.
- Regularly audit and review access. Periodically check and update IAM policies and service ID permissions.
- Implement credential rotation. Establish processes for regularly updating service credentials and API keys.
- Secure credential storage. Use encrypted storage and secure secret management systems for storing service credentials.
- Enable multi-factor authentication. For user accounts with high-level permissions, enable MFA for added security.
- Use IAM roles and groups. Leverage roles and groups to simplify permission management for multiple users or applications.
- Monitor and log access. Implement comprehensive logging and monitoring of object storage access and operations.
- Educate team members. Ensure that all team members understand IAM concepts and follow security best practices.
- Align with compliance requirements. Ensure that IAM policies and practices meet relevant industry standards and regulations.
Conclusion
In conclusion, IAM, service IDs, and service credentials form a critical triad in securing and managing access to object storage across various cloud platforms. Understanding these concepts and implementing them effectively would enable organizations to ensure that their data remains secure, accessible to the right entities, and compliant with relevant regulations.
As cloud technologies evolve, staying informed about the latest developments in identity and access management will be crucial for maintaining robust security in object storage implementations.
Opinions expressed by DZone contributors are their own.
Comments