DEV Community: Andrea Cavagna | AWS builder

AWS Console login to multiple accounts at the same time

Andrea Cavagna | AWS builder — Thu, 17 Nov 2022 13:00:00 +0000

Cloud environment is fragmented, we know it, AWS makes no exception!

While the AWS CLI already allows managing multiple accounts, the console experience is still far behind: it allows one connected session per browser instance by default.

This is a great downfall when one is frequently changing between accounts, which is normally part of the day-by-day routine of CloudOps.

So you may ask: “How can I have multiple AWS console sessions active at the same time and be able to easily distinguish between them”?

The answer could be using different anonymous browser windows or opening different browsers at the same time. Even more, I can use one of the many different extensions available on Firefox.
Are those the best options? Frankly I don’t think so…

One Web extension to access multiple console

We are developers, we love to automate everything, and we get bored doing repetitive tasks. That’s why we managed to open different AWS consoles in a single browser window, in a click. finally we integrated it in our daily routine, Leapp.

Today, I want to share with you our Leapp extension, available for all the major browsers: Firefox, Chrome, Brave, and Edge.

No more need to manage different browsers at the same time.

No need to access every time.

No need to input by yourself all the information required to log in to the different accounts.

You can create all the AWS sessions you need on Leapp; all these sessions are, by construction, related to a specific AWS Account/Role couple (if you need an introduction to AWS IAM, check this post).

With the extension installed, you’ll be able to open it from Leapp on one or more AWS Console on a specific Account with a specific role.

All in your default Browser window, without losing your preferences.

The way it works relies on isolated containers on Firefox, and on cookies for Chromium-based browsers.

Leapp extension keeps track of all the cookies in a tab that is labeled with a specific metatag and listens to all the requests and responses storing and retrieving them as needed. This is done for all the tabs currently opened in the browser.

Let’s see how to install and start using the extension!

Install your Leapp browser extension

Install Leapp

(Skip this step if you already have Leapp installed on your machine)

First, you need to install Leapp Desktop App because the extension needs it to communicate what AWS Console it has to open.

Add a session

You can add a session individually, or using the AWS Identity Center integration (ex AWS Single Sign-on). To add a Federated, Chained, or IAM User session, use the plus button in the top bar.

To add sessions via AWS Identity Center integration, use the plus button near the integration sidebar.

In both cases fill the required parameters.

(Note: at the moment IAM User sessions can’t use the extension, but all others do)

Install the extension

The extension is available for all major browsers:

If you’re on Firefox you can download it directly from the store.
If you’re on Chrome, Edge, or any other Chromium-based browser which accepts extensions, you have to manually install the .zip file you can find here.

How to use the extension

With your preferred browser opened and the extension installed, return to Leapp and select one session you wish to access via AWS Console.

The Session will be launched in your default browser in a new tab. From there on you can open new child tabs from the initial one and all of them will retain the same cookies. On Firefox, you can verify this by taking a look at the color of the session, which will be the same.

The extension comes also with a small user interface that lets you focus the tab you need based on the AWS account and role currently set in that tab.

Final Thoughts

After reading this article you may wonder why you would use Leapp extension instead of one of the many others available.

Here are my top 3 good reasons:

Programmatic meets Console access

Many tools scattered on the Internet are useful for Programmatic access (i.e. CLI tools) to AWS, while many others (typically most of the extensions for Firefox) are only used for Console access.

You can have both. In the same tool. Behaving the same way.

Secure Access

Are you managing your credentials securely? The fact is that most tools only act as a way to access AWS, but the security posture of those credentials is a burden on the shoulders of the final user.

Leapp uses and rotates for you temporary short-lived credentials, generated from your sensitive infos (encrypted in your local system) for use with any AWS-compatible tools (i.e. AWS CLI, Terraform, CDK, etc.), and for accessing your AWS console too.

Extensibility

Leapp comes with a plugin system that lets you enhance your experience by automating your everyday operations on AWS.

This reflects also on the extension, as it communicates via WebSocket with Leapp.

Finally, I would like to suggest this article on how to manage AWS credentials.

Conclusions

If you’re here, reading this article, is thanks to the time I saved in opening and closing AWS sessions. Maybe it may seems esagerate, in a way, but think about all the minutes combined everyday doing repetitive tasks, and you’ll see how much time it is!

I strongly believe that many of you have the same issue at the moment, that’s why we open-sourced this solution to everyone,

We have seen what problems it could solve, mainly for managing multiple AWS account consoles at the same time, but also because being part of a more structured tool, it does it with secure credentials and without having the user remember passwords, profile names, roles, and so on.

We have seen where to retrieve it and how to install it.

Automating processes is also your thing? Do you like to find solutions to your everyday problems, and like to share them with others? Then join our community.

Until next time thanks for reading and stay safe!

Can't miss Cloud Operations Sessions at re:Invent 2022

Andrea Cavagna | AWS builder — Fri, 11 Nov 2022 14:17:40 +0000

Today, I want to share with you the sessions and events I'm more excited about as an AWS Community builder with a focus on the best way to operate securely in AWS.

Launched in 2012, re:Invent is the annual developer conference hosted by Amazon Web Services.

With more than 60000 attendees and 2500 technical sessions, it's the most entertaining week of the year in Las Vegas.

I want to thank Chris Farris and his post for inspiring me to write this article.

The link to the session brings you directly to the Session Planner. If it's hard to schedule your re:Invent Calendar, try to use the unofficial planner.

Sessions type @ AWS re:invent

Chalk Talks

Chalk Talks are highly interactive sessions with a small audience.

Each begins with a short lecture (10–15 minutes) delivered by an AWS expert, followed by a 45- or 50-minute Q&A session with the audience.

This is by far my favorite session type for the event, and this type of session WILL NOT be available later on YouTube AWS Channel

Breakout Sessions

AWS re:Invent breakout sessions are lecture-style and one hour long. Those sessions are made by experts and will be available a week after the event in a dedicated playlist on YouTube.
Be sure to follow one if you wanna meet the speaker or ask anything from him, otherwise, you have the opportunity to learn the topic easily the week after.

Builders’ Sessions and Workshops

Builders Sessions are small-group sessions led by an AWS expert who guides you on new technology, followed by a hands-on practice of the topic.

A list of can't-miss sessions and events

- COP305 - Best practices for organizing and operating on AWS

Bianca Lankford is the Senior Director of Global Cloud Engineering @ Warner Bros. Discovery. I'm interested to hear more about a big enterprise relying on Tools and Best practices to manage a complex cloud environment.

Description:

Managing and operating cloud environments from multiple business units can be challenging. In this session, hear from Bianca Lankford, Senior Director/Global Head of Cloud Engineering & Governance from Warner Brothers Discovery, about how they organized their cloud environment to allow teams to develop with agility while being able to manage and operate their applications in a secure, automated, reliable, and cost-effective way. See how you can use AWS Organizations and AWS Systems Manager to operate your applications at scale, manage mergers and acquisitions, and develop governance as a product for your environment.

- SEC001 - Building more AWS accounts? One IAM Identity Center to rule them all

Jonathan VanKim is a Security Specialist in Cloud Systems Architecture @ AWS.
The peculiarity is that the session will be at the AWS Village in the Demo Theater. Having a networking opportunity to better access the Cloud in an Organization from a single place.

Description:

Want to simplify your workforce access with AWS IAM Identity Center (successor to AWS Single Sign-On)? This session explores how to use AWS Managed Microsoft AD integrated with IAM Identity Center. Learn how to quickly and simply manage your workforce users and scale in your AWS organizations.

- BOA202 - Take these open-source tools on your AWS adventure

AWS Developer advocate Curtis Evans and Darko Meszaros will introduce Build on Live during the event, and I can't wait to know the best Open-source tools they will explore. I'm hoping to see Leapp there, too (" Making my AWS adventure easier” was one of the main points that brought me to build the OSS tool)🙂

You've set out on a grand adventure to learn, build and expand on AWS. Like any good adventure, it has its challenges. Time to gear up! Grab your best tools and gear to help you on your way. In this session, have a look at open-source tools that can help make your AWS adventure easier. See something for security and permissions, something for cost management, and a few more things for building in the Cloud—tools like Infracost, IAMLive, and more.

- COP323 - Delegating access in a multi-account environment with IAM Identity Center

This is a Chalk talk. A smaller group talks about the problem and how to address it together. In this case, I'm particularly interested in seeing ABAC models with IAM Identity Center. Before this session, I advise watching this amazing session by Quint Van Deman (One of the best sessions I've ever attended).

In this chalk talk, learn about delegating access management with AWS Organizations and AWS Control Tower using AWS IAM Identity Center. Using customer-managed policies and permissions boundaries, you can enable a decentralized access management model with permissions guardrails that enforce coarse-grained authorization standards that apply in both role-based and attribute-based access control (RBAC and ABAC) models.

- COP318 - Setting up controls at scale in your AWS environment

Michael St.Onge, senior security manager @ AWS, will speak about the Control tower's ability to delegate access and make it easy to implement a least-privilege permission easier for AWS Users

Companies are challenged with balancing compliance and security requirements with the desire to allow engineers to make their own design choices. Many companies take an allow-list approach: restricting developer access to AWS services until risks are defined and controls implemented. In this session, learn how to use AWS Control Tower features to meet control objectives and reduce the time it takes to approve AWS services for use.

- NFX305 - Reimagining multi-account deployments for security and speed

Netflix has proven to be one step forward in many fields among Cloud operations in a multi-account strategy. Netflix Tech blog is one of my favorite resources to be on top of technology ideas. Every time I go back to this presentation by Travis McPeak and Will Bengtson to explain the level of excellence of Netflix
This time they will present a new paradigm for a multi-account deployment, take it.

In this session, discover a new paradigm for multi-account architecture based on decoupling a workload's identity and permissions from its underlying cloud infrastructure. Efforts to segment cloud environments are often stymied by complex migrations and excessive operational overhead, hindering organizations from capturing the desired security and scalability benefits. Join us to learn how Netflix is deploying applications in isolated AWS accounts without relocating their compute or network resources, and discover how they are increasing developer velocity along the way.

- NFX302 - Accelerate insights using AWS SDK instrumentation

How could you figure out an application's identity across an AWS account? It’s a question I ask myself often, and I'm intrigued to figure out the Netflix way to do so.

Migrating an application's identity across AWS accounts requires a clear picture of its identity-resource relationships. In this session, learn how Netflix filled gaps in cloud data sources by instrumenting AWS SDKs to create new categories of visibility.

Open Source Zone and Noovolari Leapp

I won't do any pitch for re:invent, but I will present Leapp at the Open source Zone (Third floor of the Venetian near San Polo and the Press area) on Wednesday from 1 pm to 3 pm.
I will speak about my open-source project Leapp and how to better operate in Cloud daily as a CloudOps.

Re: Invent is firstly a Networking event

This year will be my third AWS re:invent, so my most extensive advice is to explore our partner expo, including the AWS Village and the AWS Modern Applications and Open Source Zone.

My advice is to be prepared and look at the Partner Expo map at the Venetian before landing in Vegas.

Could you make time for a meeting with your professional network? Let people know you'll be at re:Invent (changing your Twitter and LinkedIn name is an excellent point to start from).

Do you think that your evening will be free? Not at all. There are plenty of Parties to participate in before the epic re:play party. Check them out and grab your ticket!

Final thoughts

Re:Invent, to me, is a community event and is the yearly opportunity to meet with all the Top of the Ops community we have built with Open-source.
The amount of Cloud experts from all around the world is a unique opportunity to peer and create long-term connections with many people, and this is the best part of re:invent. Don’t miss having fun and visiting all the best of Vegas.

So please, text me if you want to grab a drink together! I’m a big fan of Bourbon and Rye Whiskeys 🥃 and I will be happy to connect with you in front of a good cocktail or beer 🍺!
I hope to see you all in Las Vegas!

AWS Single Sign-on for DevOps: is CLI v2 the best option?

Andrea Cavagna | AWS builder — Wed, 13 Jan 2021 15:33:53 +0000

Going back to the 10 of December 2017, AWS introduced AWS Single Sign-On, a service that makes it easy for you to centrally manage SSO access to multiple AWS accounts and business applications.

Three years later, the Service has grown a lot, and with the increment of usage of services like AWS Control Tower and the AWS Organization in general, AWS Single Sign-on has been one of the best methods proposed by AWS to manage access in a Multi-Account Cloud environment.

But, in the first instance, users were supposed to log into the AWS SSO portal, copy the named profile credentials and paste them into their local ~/.aws/** files. That was a big waste of time and productivity for developers.

Later on, in 2019, AWS introduced the CLI V2, in beta preview, with the native support of AWS SSO.

That's been a huge leap for developers because the release included automatic short-term credential rotation enabling developers to take full advantage of CLI profiles to switch between roles, which increases their security posture.
So, let's see the good, the bad, and the ugly of this proposal.

The Good

With this integration, Developers can now initiate the same SSO flow as the portal, but with different results.

The CLI will automatically generate temporary credentials from an access Token that will last 8 hours.

Also, it applies named profiles for each access role you need.

By doing so, developers can change their account by switching the in-use AWS named profile.
The automatic short-term credential management enables developers to switch between accounts and roles seamlessly without refreshing credentials.

To run a command that refers to a particular AWS profile, you have only to add the --profile parameter:

aws s3 ls --profile my-profile

The Bad

The process is relatively easy on the developer side, but it still brings some issues.

From the CLI, you can list all the accounts you can access via AWS Single Sign-On, but you don't have the complete picture of the situation: which Role can you access in that specific account? This is not a single process via the CLI, and in most cases, that can be a significant effort.

On the credentials side, this method doesn't generate a classic AWS Role credential inside the ~/.aws/credentials with aws_access_key_id, aws_secret_access_key, and aws_session_token, but generate temporary credentials for each call. This is not a bad thing in itself.

This credential method, via CLI, is still in Beta preview, and lots of open-source projects yet don't support it.

There are still many issues online on those class of problem:

AWS SSO Named Profiles Support #5455

vikyol posted on Dec 17, 2019

AWS CLI v2 supports AWS SSO named profiles.

However, CDK CLI cannot resolve SSO named profiles yet.

$ cdk deploy --profile sso-named-profile

Unable to resolve AWS account to use. It must be either configured when you define your CDK or through the environment

Without this feature, users have to login to SSO user portal and fetch credentials for command line and CLI access, which needs to be repeated every time the credentials expire.

Even though CLI v2 is still in preview, it would be good to have this feature implemented for early adopters.

Use Case

Simplify deployments to multiple-accounts for AWS SSO users.

Proposed Solution

Read sso_start_url, sso_role_name and sso_account_id from ~/.aws/config file.
Fetch the accessToken in ~/.aws/sso/cache/ matching sso_start_url.
Fetch temporary credentials from STS using SSO.get-role-credentials() with accessToken, sso_account_id and sso_role_name parameters.

This is a 🚀 Feature Request

View on GitHub

The Ugly

Last but not least, let's identify the sore points.

Once you have been logged into the portal, in the ~/.aws/sso/cache/** you will find 2 files:

The first contains the local client id, which is required to make every API call to the AWS Single Sign-On portal, and the other includes an ACCESS TOKENthat is valid for 8 hours.

With those two objects, you can access EVERY account you can reach through AWS Single Sign-On.

That means that if someone steals your credentials files, he can access all your accounts via AWS SSO!

And the most painful part to me is that the ~/.aws/** files are accessible freely inside your local System.

We know really well that Striking a Balance between Security and Flexibility is Crucial.

But that was too much not secure in comparison to what we were gaining in terms of flexibility. So we came up with this new feature in our open-source project:

Noovolari / leapp

Leapp is the DevTool to access your cloud

Leapp

Website | Roadmap | Blog | TOPS community | Documentation | Troubleshooting

⚡ Lightning Fast, Safe, Desktop App for Cloud credentials managing and generation

Leapp is a Cross-Platform Cloud access App, built on top of Electron.

The App is designed to manage and secure Cloud Access in multi-account environments, and it is available for MacOS, Windows, and Linux.

For more information about features go to our documentation.

✨ Features

Cloud credentials generation in 1 click
Data stored locally encrypted in the OS System Vault
Multiple Cloud-Access supported strategies
Automatic short-lived credentials rotation
Automatic provisioning of Sessions from AWS Single Sign-on
Connect to EC2 instances straight away
Managing Leapp with its CLI
Create your own Leapp plugin to customize the App functionalities from the template

All the covered access methods can be found here.

Download

You can find all the information needed to download and install Leapp…

View on GitHub

Leapp and AWS Single Sign-On

Leapp is a DevTool to increase productivity for everyone that will work with Programmatic access to the Cloud.

With Leapp, you can store all personal information, such as aws_access_key_id, aws_secret_access_key, and AWS SSO ACCESS TOKEN, in a secure, encrypted place inside your local system.

Leapp integrates AWS Single Sign-On is really a one Click process and automatically generate ALL the Session that a Developer can access, from a single view:

An important point here is that Leapp generates only short-lived temporary credentials in the ~/.aws/** files, in the straightforward form, with AWS access key, AWS secret key, and AWS access token.

By doing so, this makes every credential generated from AWS Single Sign-On with Leapp fully compatible with every Library and project that uses Programmatic access to AWS.

Also, AWS Single Sign-On is not the only credentials method supported by Leapp at the moment; it manages and also secures IAM Users, cross-account Role-based Access, and federated Access through GSuite.

Final Thoughts

Isolate workloads have become a good practice in AWS, and create an AWS Organization has become a standard in the last years.

How to access multiple and heterogeneous accounts has always been an overhead that has been simplified with AWS SSO.

But to me, is always important to keep an eye on the security side and that's why I would choose Leapp over accessing via the CLI directly.

If you aren't sure if the AWS Organization is the best option for you, I think the article of Cloudonaut is a must-read for you.

AWS SSO VS Cross-account role-based IAM access. Why and how to use roles?

Andrea Cavagna | AWS builder — Mon, 12 Oct 2020 14:56:34 +0000

Considered to be the best practices in AWS, one of the most popular ways to maximize AWS's potential is to utilize multiple accounts.

An account enables you to run multiple workloads and draw a line on three crucial aspects:

Billing and Cost Management
Identity and Access Management
Limit Resources and API Request Management

Firstly, AWS encouraged creating multiple accounts, developed Consolidated billing to group all the billings of an AWS environment.

Then, in 2017, it introduced AWS Organization.

If we focus on IAM and access management, with Organization, AWS SSO has come as a gamechanger for a large number of situations.

Anyway, there are many circumstances where applying this kind of structure doesn't fit the needs, for example:

Large Companies, where the Identity Provider is locked up in many sub-companies: as the company grows, or if a company with his Identity Provider got acquired into another, unifying access in a single point can be significant pain.
Consulting partners: If you are a consulting partner, you probably have to isolate Organizations for each customer you have, which can't be done with a single organization and a single AWS SSO. Moreover, in the case of reselling, centralized billing and reserved instances at the organization level doesn't work, too.
More than 50 accounts Organizations: the need of getting isolation for the workflows through accounts is difficult to achieve, and the danger of a blast radius in case of breaches is enormous.

Even if AWS SSO provides several benefits, in such cases, the problem of managing multiple-account access remains.

Also, using AWS SSO is not permitted if you are not the owner of ALL the accounts. This situation will cut out smaller companies acquired by bigger companies.

The downside to using multiple accounts, without organization, is the necessity to provide various logins to each person that needs access.

For example, each DevOps Engineer may have credentials to their sandbox account, internal company accounts, developer accounts, and client accounts.

Providing a security best practice, such as password rotation or not reusing the same password between more accounts, could be challenging to apply.

To manage this situation better, the help of STS and cross-account role-based IAM access is crucial.

Cross-account role-based IAM access

A single IAM Role can have specific permissions (i.e. development-role, marketing-role) into a single account.

Then an IAM user can access a different account with a specific IAM role through STS with the AssumeRole action.

This is the turning point.

You can now isolate a group of accounts where a single organization entity manages access individually.

Now isolating the environment in a workload is easy and it respects compliance. But still there are many topics to pay attention to.

The environment

Let's start from the beginning.

AWS IAM...

If you still don't know what Identity and Access Management (IAM) are, here's a quick recap:

AWS Identity and Access Management (IAM) enables you to manage access to AWS services and resources securely. Using IAM, you can create and manage AWS users and groups, and use permissions to deny their access to AWS resources.

So basically, it is the AWS framework that lets you decide who can access what on your account. Mastering this service is the first step in securing your AWS account, but let's see what IAM users are and why they are important.

... Users!

This is the most widespread and easy access method in all AWS.

An AWS Identity and Access Management (IAM) User is an entity you create in AWS to represent the person or application that leverages the account to interact with AWS. A user in AWS consists of a name and credentials.

With a User, we are going to represent each person that has to access the Cloud services.

This user should have only permission to assume some particular role in other accounts, so he becomes the permission manager on what account each developer can access to.

... Roles

A Role is the most versatile entity in AWS IAM.

An IAM role is an IAM identity you can create in your account that has specific permissions.

The fact that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS, makes it similar to an IAM User

However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it.

We will manage what kind of permission it will have in an account at that particular moment with roles.

So let's start!

How to manage infrastructure

On a Gateway account.. (AWS Account "A")

We will create a User that will serve as a bridge to all other AWS accounts the person with this User needs to reach.

Firstly create the User and then attach a policy with the only permission to assume a role in another account.

The AWS policy should be like the one below.

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": "sts:AssumeRole",
        "Resource": "arn:aws:iam::123456789012:role/developer"
    }
}

With this policy, we are permitting the user "john.doe" to assume the role of "developer" in the account "123456789012".

On the Truster account.. (AWS Account "B")

Now switch on the landing account ("Account B") and create a role that the user "john.doe" can assume.

N.B. remember to specify the truster identity, with the account id of the Gateway Account.

Next, add the permission needed for the specific role.

Through this simple tutorial, we have allowed "john.doe" to access the "developer" role in the Truster account ("Account B")

What about the Developer side?

Adding the Gateway Account...

On the developer side, at this point, the only credentials needed to access to every account are the "Access key I.D." and "Secret access key" of the User in the Gateway account ("Account A").

Storing that info in a secure and encrypted place in your local system is essential.
That's how Leapp comes to help.

Leapp is going to save "Access key I.D." and "Secret access key" in the System Vault (like "Keychain" for MacOs, "Credential Vault" for Windows, and managed by "Secret Service API/libsecret" in Linux)
That's the advantage of using Leapp over storing Credentials in the ~/.aws file*.*

In Leapp, under the "AWS" provider and the "Plain" access strategy, we are going to fill in all the needed info to connect to our Gateway Account:

Now our credentials are secured, and we can create a credentials session with this User directly from the Desktop App.

The Truster Account..

No more credentials are needed to access a role in a Truster account!
So, simply add a new session:

By selecting "Truster" as an access strategy, you only have to add info about the account ("Account B") alias and number, then the role name you have to assume, in our case, "developer."

After doing so, we have to select the account Gateway ("Account A") from where we access the "developer" role.

With Leapp, when the session is set to active, the App is going to call the STSAssumeRole call to retrieve the pair of access key and secret key needed to work on the current role.

Also, the credentials are frequently rotated without having to worry about them!

In this article, we have described the right situation for the right environment.
We walked through the configuration of Cross-account role-based IAM access both from the Manager and the Developer point of view.

If you are interested, like us, in this topic, follow us on our Medium Publication for the second article of this series, which is coming the next week.

P.S. Curious about Leapp? Check out the Repo to meet the project and follow its development.

%[https://github.com/Noovolari/leapp]

Is this environment fitting with your company? Need any help in implementing it?
feel free to contact me!

That’s why your next business have to be focused on Developers

Andrea Cavagna | AWS builder — Mon, 21 Sep 2020 14:43:34 +0000

Over the last twenty years, Saas and Cloud have been the two emerging technology sectors.

Everything started with Saas. Salesforce went public 16 years ago, and many other companies have followed his example.

This business model relies on the idea of changing the purchasing model by eliminating licensing, installing, and other pain of traditional software.
Today the value of SaaS solutions exceeds $1.7 trillion.

Then public Cloud has risen after the launch of AWS by Amazon, Azure by Microsoft, and GCP by Google.

Many companies started building their software and business in Cloud.

Now a new emerging sector is growing: developer-driven software.

Unlike in the past that languished due to developers' inability to pay for expensive, "packaged" tools, these newer products are available online, often free, open-source, or at low cost, and shared widely across the global developer community.

Open-sourcing enables a community of developers to improve functionalities over time, providing public APIs and SDKs that make the product flexible to fit into many companies.

Developer-driven software

Every company is a technology company, no matter what product or service it provides. The companies that embrace this fact are the ones that shape our world.

Says Stephenie Stone, in "Why Every Company Is A Technology Company"

That's why developers are impacting more and more in the business model of a company.

From a tech point of view, the market of companies that aim to help power software development will grow significantly.

According to Evans Data Corporation, there were 26,4 million software developers in the world in 2019, a number that in 2023 is expected to grow to 27,7 million and 28.7 million in 2024. The USA is taking the leading position by the number of software developers reached 4,2 million.

With this increasing number of developers, every time you have to start building a business and thinking about a business model, you have to start thinking about developers.

But the problem is: how are companies supposed to generate millions in revenue selling to developers?

*Developers have not budgeted in a company to improve software development. *
They are looking for free or open-source software that can help them accomplish their goals.

The answer starts with winning the hearts and minds of developers before trying to sell them anything. If they adopt the product, they can contribute, use it, and spread it across the community.

So, how to generate revenue in this situation? Three business models have successfully appeared to commercialize developers love:

Freemium
API-based services
Commercial Open-Source (COSS)

Let's analyze them better:

## Freemium

How does it work?

Freemium is a two-tiered user acquisition model, where a slight version of a product is available for free or in free-trial to help the adoption.

The main goal of this acquisition model is to decrease customer acquisition cost (CAC) for the product.

Freemium aims to create several loyal users and then transform them into paying customers as a next challenge.

Pros

If many developers can try out the free part of the product, the opportunity arises to build a large, engaged customer base.
Avoid overspending on paid marketing channels and focus more on building trust in the product.

Cons

You have to convince the development team to a paid model.
Competitors can copy the freemium version, but offering more for free, undercutting a well-thought-out revenue model.

Winning Example

Slack is a company that has fully exploited the benefits of a Freemium business model.
Slack started as a product "built by developers for developers."

The app's basic functionality has always been free, and only a part of the software comes in a paid solution.

Slack's win situation is that many Developers start using Slack and tell other colleagues and people in their communities, accelerating the product's flywheel.

But for sure, the difficult part is to get the flywheel spinning in the first place; developers still have to know the product and try it out.

API-based services

How does it work?

In most cases, APIs are the building block of a product.

The goal is to accomplish critical functionality commonly used by developers quickly and flexibly, so tasks such as payment processing or messaging.

The most critical problem for a developer is always time, with many pressured releases and strict specs to follow.

There are three different charge service fees commonly used:

subscription fees (developers pay a monthly fee)
consumption fees (developers pay a fee each time the API is called)
transaction fees (developer pay a percentage of each purchase completed via API)

Pros

APIs are flexible enough to cover most of the common cases that a developer needs. To do so, you have to listen closely to what they need and educate developers in forums, conferences, and virtual events.
By integrating an API into a product, it will produce a stable stream revenue.

Cons

Some developers can eventually decide to build their API to emulate the third party API into their products.

Winning Example

Stripe was created with the primary goal of making the implementation of payment systems easier.

Stripe makes it easier for everyone to make and receive payments. It allows developers to start creating and accepting payments by adding a few code lines to their product.

The leading cause of their success is that it offers a payment system simple, straight-forward, and easy to implement (and documented through the most well-written Docs I’ve read by far).

They focus on making the product developer-focused, and by doing so, they beat all other competitors.

The company's first funding was provided by Paul Graham, the founder of Y Combinator.
This seed of investment of $2 million helped to get the ball rolling on Stripe. The service became an immediate success. By 2014, Stripe was processing billions in transaction volume and present in over 12 countries.

Commercial Open-Source (COSS)

Last but not least, the most complex and intriguing one.

How does it work?

COSS is not a development-driven business model, but most of the code is written by the dev community while addressing to the dev community itself

In this business model, the core of the product is open and can be developed by anyone. Then only some premium features will be charged at the middle-enterprise level.

Many developer users may also contribute to an open-source product or other integration of it, making the core product more useful and valuable.

Frequently, the paid section of a product comprises enterprise features that include security and governance (such as SSO access to the product), collaboration, or high-availability.

Each company that is approaching this business model has a clear and transparent roadmap to all the community.

The trick is to provide useful functionality in the open core, so developers rally around the product, creating a groundswell of enthusiastic users.

Rarely do open source projects gain rapid user adoption on their own.
Expect that only because the project is on GitHub is gaining attention is not right.
Marketing, communication, and content have to be structurally changed from other business models.

Developers have to trust your project as the first thing. So you have to participate as many conferences as you can, host meetup, do technical conferences, communicate with other developers, and to respond to feedback on social media.

Pros

Lower friction to developer adoption.
Adoption rely on Word of Mouth, not conventional marketing
If the open-source product gain attention, you don't have to take massive marketing at the enterprise level. Developers of the company will push themself to the adoption of the product.
Create a virtuous cycle between technology innovation and business innovation. More people use the product means more feedback, that means more support to give, more premium feature, and so on. (We will talk about this in another article later)

Cons

You have to manage to distinct Roadmap, one for the open product, and one for the close product. It is essential to be clear from the beginning
The adoption is slower than a Close source product. So it is fundamental for the product to find someone that believes and invests in the project.

Winning example

Hashicorp is a company born in 2012 from an open-source project of Mitchell Hashimoto and Armon Dadgar.

And as he said: "We started the projects and never planned on making a company. It's totally fine that some people have ideas, and they do it to start a business, and that's normal."

Hashicorp bases his platform on the open-core product with specific enterprise features, with the goal to provision, secure, connect, and run any infrastructure for any application.

As Glenn Solomon says in "The Next $1 Trillion - Three Ways To Win Developers' Hearts And Minds" :

I invested in HashiCorp in 2014 and remembered the founders flying 250,000 miles a year back then just to visit developers at conferences, and spending thousands of hours working with them to gain insights from users about HashiCorp's early products.

This is exactly what is needed to gain popularity in an open-project.

Now the company is rising in the world of the Multi-Cloud:

Final Thoughts

Some months ago, a couple of friends and I started a long journey with an idea in mind: turning a project we strongly believed in into action.

Finally.
We sifted through many and many ideas trying to figure out which business model would be the best to support our rising product idea, intending to create something valuable and useful to help developers and companies to improve their work experience.

We came out with this and many other thoughts on which is the best sector and business model to be applied when you are working on creating a B2B product focused on Tech, and we are happy to share all this with you.

Are you starting your new product? Hope this can be the first step in your journey towards the success

References:

Single-sign-on with G Suite on the Amazon Web Services console

Andrea Cavagna | AWS builder — Wed, 09 Oct 2019 15:46:04 +0000

Which AWS console user has never run into the age-old problem of managing multiple users on multiple accounts, having to create different IAM users — with complex passwords for each of them — on top of the highly fundamental (but, let’s be honest, decidedly inconvenient) two-factor-authentication?

And on the topic of two-factor-authentication, assuming that you don’t want to use a dedicated hardware token for every single IAM user, the choice is almost totally limited to Google Authenticator, with codes and QR codes that proliferate like mushrooms and that become difficult to safeguard from adverse smartphone-related events (theft, loss, breakage, backup, changing device…).

AWS actually offers a cross-account access service for its management console, which, however, has several limitations, including:

the maximum limit of 5 manageable AWS accounts [UPDATE: this limit has been removed :)];
being based on the cookies of the browser used to log into it (if we change browsers or delete the cache, everything gets reset);
its requirement for at least one “master” IAM user to start with, which requires dedicated login and TFA credentials.

The most appropriate response to the need to centrally manage users and login details, for AWS as well as for the vast majority of applications that need multi-user authentication, is called Single-sign-on (SSO).

Typically, the SSO mechanism is based on an Identity Provider (a centralised repository of all corporate identities with their attributes — username, password, groups, roles, etc…) and a series of Service Providers (applications where users can log in with their corporate identities) that are federated to the Identity Provider with strong trust relationships that are typically based on shared keys, certificates or tokens. This allows users to use a single user profile (and therefore a single password and a single TFA), which is centrally managed, to log into all the applications that have been enabled for them.

Although Service Providers can be the most disparate of applications (Web, desktop, mobile, remote access, CLI, API etc…), Identity Providers are almost always LDAP or Microsoft Active Directory servers. Specifically, MS AD is the de facto standard in most highly-structured companies for corporate identity management, and it is therefore supported by default by all applications that require the option of using SSO.

However, it is not that common to find an MS AD infrastructure implemented (but this also applies partly to LDAP), especially in smaller, younger or more agile businesses, for reasons ranging from cost to complexity of management (especially if they are in need of a highly reliably provided AD service), without ignoring the fact that MS AD is typical of Microsoft-centric companies (almost all the large legacy companies) and is therefore less prevalent where the client base is more varied (Windows+Mac+Linux…).

A very widespread trend in businesses is to use the company Google Apps account (recently renamed to G Suite) — a widely-used service mostly used for its email and collaboration functions — as an Identity Provider. By doing so, you can use SSO on a multitude of applications that already natively support the “login with Google” function, but also on those (as is the case with the AWS console) that support the SAML standard, which G Suite has been providing the service of Identity Provider for for around a year.

So let’s see how to configure our AWS and G Suite accounts to make Single-Sign-On work with SAML.

First of all, in the G Suite administration page, we have to add custom attributes to our users, through which our Identity Provider (Google) will communicate the identity of the user logged in, as well as additional information that we will explain later, to the Service Provider (AWS).

Now create a custom attribute class and call it “AWS SAML” and then create the attributes “IAM Role” and “SessionDuration”. It is important for both attributes to be private (that is, not viewable by all users in your organisation) and for the attribute “IAM Role” to support multiple values.

With this done, go into the “Apps” section and add a new SAML application, starting with the preconfigured template for AWS.

Download (option 2) the IDP Metadata (which is an .xml file that contains some configuration parameters and the X509 certificate that the _trust_relationship between IdP and SP is based on) and set it aside for a later step.

WARNING!!! The contents of this file should not be released for any reason; the security of the entire solution relies on its remaining confidential!

We continue the configuration by mapping the SAML entity known as “Name ID” on “Primary Email” (that is, the user will be presented to the AWS console with their email address as their unique identifier).

In the next step, we need to configure three additional mappings (be careful, as here the G Suite UI is not very clear, as the URLs in the left column aren’t very legible):

The attribute https://aws.amazon.com/SAML/Attributes/RoleSessionNameshould be mapped to “Primary Email” again.
The attribute https://aws.amazon.com/SAML/Attributes/Role should be mapped to the custom attribute “IAM role” that we created earlier. What we are doing with this is telling AWS which roles the user is authorised to take on and on which accounts.
The attribute https://aws.amazon.com/SAML/Attributes/SessionDurationshould be added, mapped to the custom attribute “SessionDuration” that we created earlier. Here, we are telling AWS how long the session of a particular user should last before they are automatically logged out.

It is very useful to be able to customise this parameter because the default session is 1 hour long, which, for people who work quite a lot on the AWS console, is very short, leading to many inconvenient forced logouts during daily operations. WARNING!!! This “trick” is exclusive to beSharp; it is not documented in the official Google or AWS guides! (nda).

At this point, the configuration of G Suite is finished and we move on to the configuration of AWS.

We go into the IAM section –> Identity Providers and create a new one, SAML type, which we will call “GoogleApps”; at this point, we will have to upload the IdP metadata that we downloaded earlier (once the file is uploaded at this point, I suggest deleting it from your computer).

Then we create a new IAM role that we’ll call “GoogleLogin” and as the role type, select “Identity Provider Access” –> “WebSSO” and associate it with the “GoogleApps” Identity Provider we’ve just created.

In the next steps of the wizard, we will associate a policy with the IAM role to provide the permissions (in our example we gave admin permissions — DON’T TRY THIS AT HOME!!!:) ) and the configuration on the AWS side is complete.

Now we turn to the administration of G Suite, to assign individual users permissions according to which roles they can take and on which AWS accounts.

This is the least intuitive part of the configuration: with regard to the roles and accounts that are accessible, AWS expect values like this from Google:

arn:aws:iam::1234567891012:role/GoogleLogin,arn:aws:iam::1234567891012:saml-provider/GoogleApps

As you can see, these are two ARNs separated by a comma. The first is the ARN of the role that that user can assume, the second is the ARN of the identity provider that we created within the AWS account. (The number 1234567891012 is a placeholder that must be replaced with the actual account number of your AWS account). This value must be entered in the custom field “IAM role” that we created earlier. This allows us to specify which role each user can take on and on which AWS account.

If you remember, we made sure that the “IAM role” attribute supported multiple values; indeed, it is possible to specify multiple roles for the same user within the same account, or even on different accounts. Simply add more tuples such as:

arn:aws:iam::112233445566:role/Ruolo1,arn:aws:iam::112233445566:saml-provider/GoogleApps
arn:aws:iam::112233445566:role/Ruolo2,arn:aws:iam::112233445566:saml-provider/GoogleApps

and immediately after logging in we will be asked which role we want to assume on which account.

Of course, for everything to work properly, in our example we should also repeat the SAML federation process (exchanging the IdP metadata) for account 112233445566.

In the custom field “SessionDuration”, you can specify the duration of the login session in seconds for each user. I suggest the value 28800, which corresponds to 8 hours: more or less a typical workday.

At this point, all we have left to do is enable the SAML application that we created, and all users will find a new icon in their quick access menu for Google Apps.

We’ll log in with our test account “Mario Rossi” and, by clicking on the corresponding icon, we will magically be directed to the AWS console where, as you can see, we are logged in with our federated account, m.rossi@besharp.net.

Satisfied?

In the next article, you will see how we used — in a very creative way — the same approach based on G Suite and SSO to use AWS services that require authentication using a key/secret pair, such as AWS CLI, CodeCommit and access to APIs from clients outside the VPC.

In subsequent articles, on the other hand, we will further develop how to use G Suite as an Identity Provider for all the other services that would normally require a federation with Active Directory or LDAP.

[09/09/2019 — UPDATE: You’ve spoken… and we’ve listened! Thanks to your hundreds of emails, tweets, and comments, we’ve understood that our solution could have helped many other developers and DevOps all around the globe. So, we are proud to present you Noovolari LookAuth!
With LookAuth you can easily manage programmatic access via Single Sign-On with G Suite directly to all your Amazon Web Services Cloud accounts. Sign up today for the beta version, it’s FREE!]