Securing Hybrid Cloud Object Storage with MinIO IAM

Enterprises continue to expand their cloud footprints - running more workloads across more clouds - public, private and edge. They are seeking cost-savings, scalability and better time-to-value, but they risk losing these benefits to complex and often redundant cloud deployment and management strategies. Protecting resources in the cloud can quickly become an overlapping mess of entities, permissions and policies.  

There is hope. Existing enterprise security paradigms are adapting to meet the challenges of extending the IT footprint into the cloud. While there are many layers to an all encompassing defense-in-depth strategy, this blog post focuses on the role of Identity Access Management (IAM), a key mechanism to control permissions and access to resources for users and services, in protecting cloud resources and data.

According to Verizon’s 2021 Data Breach Investigations Report, eighty-five percent of breaches involve some kind of human element. Privilege abuse was the top type of misuse in breaches. While it is not clear whether these breaches took place in the cloud or some other enterprise environment, it is clear that IAM can have a positive impact mitigating these risks. Enterprises have long known that clear and enforceable access policy built around identity can prevent compromised data and services, and limit their scope should they occur.

IAM is of particular significance in controlling who or what has access to which data and the applications that provision and manage the storage underlying that data. No one, internal or external, known or unknown, should be able to view, change or access data unless they are explicitly granted privileges. This is a tall order in environments where IT has total control and can be almost impossible to accomplish across a sprawling hybrid or multi-cloud environment built on multiple provider solutions. Relying on multiple interfaces to manage multiple providers and multiple object stores can be nothing short of a nightmare.  

In contrast, MinIO runs anywhere and is deeply integrated with each cloud provider and Kubernetes distribution to streamline managing access to object storage regardless of its location. MinIO includes internal identity management functionality and supports leading third-party external identity providers (IDP), enabling SSO for access to objects and the MinIO Console itself.    

MinIO IAM is fully AWS IAM compatible and relies on standards to support external identity providers such as ActiveDirectory/LDAP, Okta and Keycloak. This enables identity-based access controls that provide the same functionality, such as SSO for services and users, across diverse public, private, multi-, hybrid clouds and the edge.

MinIO IAM Basics

In general, IAM is about identity and access control. Implementation details and functionality vary between cloud providers, cloud-based services and local services. Basically, IAM maps identities onto access policies to define who (in the case of a user) or what (in the case of a service) has access to which applications, services, data and infrastructure components.

MinIO includes internal identity management functionality to accomplish this using the ubiquitous access key and secret key credential framework. MinIO IAM controls access to cloud resources using granular policies written in AWS IAM-compatible JSON syntax to define access to resources by users, service accounts and groups. MinIO interoperates with each cloud’s IAM (Google Cloud Platform, Amazon Web Services, Azure) and with Identity Providers such as Microsoft ActiveDirectory and LDAP to map user accounts from the enterprise onto specific access roles. For example, MinIO can use IAM policies designed for use with AWS S3 or S3-compatible services.

A general process for establishing identity-based security controls is for administrators to create individual user and service accounts, each with its own credentials. Enterprises typically manage permissions for multiple users together as a group. Groups can correspond to department or job function (or both) to simplify addition, change and removal of permissions and accounts. This is more efficient than managing users individually and decreases the potential for human error.  As policies are created, they’re assigned to groups. As users are added to those groups they inherit the group access policies. I probably don’t need to say this, but there may be someone who needs to read it: Don’t give root access to your organization’s cloud provider account to anyone.  

A MinIO access control policy is a JSON document that explicitly lists operations that are allowed or denied. Policies are granular down to a specific action on a specific bucket.  By default, users and services don’t have access to any resources until they have a policy applied. With every service and user request, MinIO applies access control policy to regulate access to buckets and objects.      

In MinIO, service accounts streamline provisioning accounts for new applications. Developers can create service accounts, simple identities that inherit permissions from the user account that created them.  

The most straightforward way to use MinIO IAM is to create static credentials. As service and user identities are created, MinIO provides access key and secret key credentials. The vast majority of identities created within MinIO are for services, not users. Applications must authenticate using these credentials every time they perform operations on a MinIO cluster. As service credentials are often long lived, we recommend creating one identity per application to mitigate the potential risks of leaked credentials.  

However, there is only so much operational scale you can get from a static mechanism. MinIO IAM can dynamically provide temporary credentials and apply access controls leveraging a combination of an internal security token service (STS) and roles, identities that have specific permissions and temporary credentials assigned to them. IAM roles are used to temporarily apply an IAM policy to users and services. When a user or service assumes a role temporarily, their initial permissions are revoked while they take on the permission of the role.

Dynamic credentialling prevents granting credentials unnecessarily. It is a best practice not to embed credentials in application code where they may be compromised. If embedded, changing or rotating the credentials would require a code update. Instead, an application or VM instance can assume an IAM role and receive the necessary temporary credentials when it requests access to, for example, a storage bucket, then access the bucket adhering to the IAM role’s permissions. Managing permissions this way removes the need to edit a user, service or group’s policy each time a change is required.        

MinIO supports OpenID Connect compatible providers to enable SSO for users, services and applications. In this case, applications must implement MinIO STS to request temporary credentials for MinIO resources. Temporary credentials are short lived and generated dynamically when requested, eliminating the need to embed them in code or to reuse credentials to provide access to datastores.

Enterprises typically manage IAM in a centralized system that relies on identity federation to share identity across applications and clouds. For example, many enterprises authenticate users on their own network, and then provide access to cloud resources using Single Sign-On (SSO). A typical way of doing this is that users log into Microsoft Active Directory, and a combination of Active Directory Federation Services and AWS STS grant temporary user credentials without the need for IT to create AWS accounts for those users.

Users can also sign in using third party identity providers (IDP) that are OpenID Connect (OIDC) compatible. Users log in to an IDP that requests temporary permissions to use cloud resources. This is commonly used to provide access to mobile or web applications without having to create custom login mechanisms and manage identity. This helps keep cloud credentials secure while improving code portability.

MinIO IAM Enables Secure Hybrid Cloud Object Storage

MinIO IAM regulates access to cloud resources, including object storage. Managing users, groups, roles and access privileges across multiple clouds can get very complicated very quickly depending on which object storage solution(s), cloud provider(s), IDP(s) and IAM providers(s) are used. MinIO provides strong identity-based controls that are interoperable and standards compliant to protect object storage, a critical component of any cloud infrastructure.

Download MinIO to get started and if you have any questions to join our Slack Channel, drop us a note at hello@min.io or use the Ask an Expert button. We are here to help you - whichever interface option you select.