As a partner solution architect, I am asked to marshal company resources to help develop and test next-generation app integrations. It’s no surprise that I have many accounts on a wide variety of cloud infrastructures for development and test purposes. In my role, I routinely sign into developer, staging, production and sandbox accounts. I also manage access for internal and external WebDev, TechOps leads, TechOps engineers, technical marketing, and automation engineers. My individual world mirrors the best and worst of a typical enterprise.
Like an enterprise, hosted infrastructures must be scalable (easily spun-up/down), secure with least privileged access, very visible and accessible to a variety of users and administrators. Yet, Infrastructure as a Service (IaaS) platforms can’t meet these requirements at instantiation. The default starting condition is a subscription which is tied to just one Admin-subscriber. This is most – not the desired least privileged access.
Where Does OneLogin and Identity Management Come In?
No longer an oxymoron, cloud + security is achievable with identity management best practice. OneLogin provides cloud admins an “easy-button” to parse out sub-account application access without permitting user self-administration. In fact, our users enjoy many such “easy-buttons.” Once inside the OneLogin Single-Sign-On (SSO) portal, users see all of their available applications, projects, resources, or access-jump-points in a tiled layout as they are added or removed from projects. They needn’t know the login and password for these resources—in fact, we don’t want them to know. My users are never allowed administrative controls beyond their role on the project, because their work is transient.
I can quickly spin-up multi-cloud test/dev environments because OneLogin (serving as the identity provider: IDP) has pre-established trust relationships with all of my cloud service providers (IDP to SP). With modern authentication via SAML SSO, OneLogin sub-admin users enjoy pre-provisioned access to resources appropriate to their project role and none they shouldn’t see. Access is further secured with adaptive multi-factor authentication (MFA) to ensure my users prove who they say they are and may only access applications if the conditions are appropriate.
In my multi-cloud, multi-user environment, everything would quickly fall apart if I were forced to manage multiple accounts and roles individually for each IaaS vendor interface. I’d quickly lose track of my users, inviting the security risk that comes from lingering or orphaned access. Achieving least privilege IDaaS (Identity as a Service) goodness begins with robust role-to-attribute-based provisioning. OneLogin’s platform easily accommodates multi-account and multi-cloud provisioning, because the required user roles and attribute tags already exist for each unique user in my IDaaS directory. Simple mapping of the OneLogin SSO attributes to their counterpart subscription capabilities, once for each cloud IaaS, will subsequently keep all users synchronized thereafter.
OneLogin and Amazon Cognito Integration
Although I also use Azure, Google and IBM platforms, I prefer the flexibility of OneLogin’s unique API synchronization with Amazon’s AWS Cognito service. Beyond two cloud provider’s parallel IAM directories is a complementary value-add privilege afforded provisioned OneLogin/AWS sub-administrators. Since a single user can have multiple simultaneous roles/privileges in AWS, OneLogin preserves the concept of least privilege management during the SSO process and allows the user to select which of their many possible roles or resources they need for that particular session in a one-click experience. The AWS/OneLogin API integration permits the most granular access with the fewest number of pre-determined mappings for my trusted users. The value-add least privilege feature forces users to choose their role from a pick-list of available roles for that session’s activities. Because each project can be defined as a separate AWS application (even if triggering access for the same AWS host account), there are fewer tiles to create and manage for the one to many relationships.
Partner projects are often delivered as self-contained AWS EC2 instances rather than as Docker containers. For these whole operating systems, a web RDP or Linux SSH session may be required for access. In the AWS world, this means a certificate must be downloaded for each sub-administrator. Because I lose visibility to commands executed within the OS following certificate authentication, I rely on the transitive trust relationship, I rely on the transitive trust relationship from my PAM (Privileged Access Manager) provider (using Trusted IDP) to watch and record access while ensuring no resources are abused (it’s a subscription after-all). OneLogin provides access to the PAM and the PAM provides access to SSH or RDP launch points (recording activity for replay when needed).
As an admin whose corporate directory is already hooked into my demo account-world, AWS multi-account setup is a “snap”. For OneLogin users, roles usually map right to the AWS service provider roles and I only need to assign a project tile to that user. Deep-link APIs enable accounts and roles to synchronize between OneLogin and AWS Cognito. Sub-administrators have the freedom to visualize and select their session’s mutually exclusive privilege. Likewise, PAM access synchronizes with OneLogin (IdP to IdP) if a user requires RDP or SSH privilege. When the user’s access control is altered in OneLogin, they lose downstream access in AWS. It’s that simple.
The nature of the multi-cloud problem set I must solve is more than equally matched by OneLogin’s multi-role provisioning. Together with a PAM tool, I have secure one-click access to all of my projects and resources in a clean, tiled view. OneLogin’s flexible mappings will work similarly for role provisioning into Azure, Google, IBM and any number of PaaS offerings transforming the way we access applications/resources. My OneLogin IDaaS multi-clouds IT all in one place.
Typical parallel roles in AWS might include privileges for domain access, email, and department membership. My users don’t need to wade through thousands of options included in Azure, Google, and AWS’s admin panels. Instead, all my web developers get access to just a few AWS sub-admin roles and each project is bundled into a single, auto-provisioned tile. When users click a project tile, they arrive at a screen that shows the AWS roles they’ve been assigned (e.g. S3Full_Access, EC2PowerUser, Route53 readonly, DynamoDB_Full_Access). Upon selection of a role for that session, they are not prompted for any more logins/passwords–the user is dropped into the familiar AWS console andaccess is approved or denied for each resource based on that role’s permission.
Managing multiple cloud environments creates a unique challenge. Join us for AWS Re:Inforce at Booth 325 to learn how our unified access management solution simplifies administration, reduces IT costs, and improves user experience.
