Forem: Toru Takahashi

Listing IAM Roles for Your Current AWS Account

Toru Takahashi — Sat, 10 Jan 2026 22:08:57 +0000

Introduction

Ever tried to create or update a resource in the AWS console, only to find out you don't have permission?

If you've worked with AWS, I'm sure you've been there. I know I have - more times than I can count. Each time, I have to check which IAM roles are attached to my account and send a message to our infrastructure team asking for the necessary permissions.

In most organizations, AWS accounts follow the principle of least privilege, which is a security best practice. It minimizes the risk of granting excessive permissions. However, figuring out exactly what permissions each person needs for their specific use case can be tricky.

As your organization grows, so does the frequency of "I don't have permission" requests. When this happens, you'll want a quick way to check what roles your account actually has.

I Built a CLI Tool to List IAM Roles

Since checking IAM manually every time gets tedious, I created a command-line tool that displays all attached roles at once. It's called canido. canido means "Can I do?".

https://github.com/tttol/canido

With canido, you can quickly see all the roles attached to your currently logged-in AWS account.
Here's what it looks like:

% canido

--- Checking AWS credentials ---
Target role: AWSReservedSSO_CanidoInlinePolicy_f1d7ab46757a3473

==================================================
  1. Managed Policies
==================================================
[Policy ARN]: arn:aws:iam::aws:policy/IAMFullAccess
{
  "Statement": [
    {
      "Action": [
        "iam:*",
        "organizations:DescribeAccount",
        "organizations:DescribeOrganization",
        "organizations:DescribeOrganizationalUnit",
        "organizations:DescribePolicy",
        "organizations:ListChildren",
        "organizations:ListParents",
        "organizations:ListPoliciesForTarget",
        "organizations:ListRoots",
        "organizations:ListPolicies",
        "organizations:ListTargetsForPolicy"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ],
  "Version": "2012-10-17"
}
--------------------------------------------------

==================================================
  2. Inline Policies
==================================================
[Policy Name]: AwsSSOInlinePolicy
{
  "Statement": [
    {
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Effect": "Allow",
      "Resource": [
        "*"
      ],
      "Sid": "Statement1"
    },
    {
      "Action": [
        "secretsmanager:DescribeSecret",
        "secretsmanager:GetRandomPassword",
        "secretsmanager:GetResourcePolicy",
        "secretsmanager:GetSecretValue",
        "secretsmanager:ListSecretVersionIds",
        "secretsmanager:ListSecrets",
        "secretsmanager:BatchGetSecretValue"
      ],
      "Effect": "Allow",
      "Resource": [
        "*"
      ],
      "Sid": "Statement2"
    }
  ],
  "Version": "2012-10-17"
}
--------------------------------------------------

The implementation is straightforward - it calls the following AWS CLI commands in sequence and formats the output:

% aws sts get-caller-identity
% aws iam list-attached-role-policies --role-name MyRole
% aws iam get-policy-version --policy-arn ... --version-id ...

For macOS users, installation is available via Homebrew. You'll need to tap the repository first:

brew tap tttol/tap # Add the tap
brew install canido # Install canido

For Linux, you can install from the binary release. This method also works for macOS:

# For x86_64 (Intel/AMD)
curl -LO https://github.com/tttol/canido/releases/latest/download/canido-x86_64-unknown-linux-gnu.tar.gz
tar xzf canido-x86_64-unknown-linux-gnu.tar.gz
sudo mv canido /usr/local/bin/
canido --version

Windows users can follow the Linux instructions using WSL2. Unfortunately, I haven't prepared binaries for Command Prompt or PowerShell (mainly because I don't have a Windows environment to test with).

Design Decisions

Focused on the Essentials

I kept canido laser-focused on one thing: "display IAM roles attached to the currently logged-in AWS account." Any other features were deliberately left out. I could have added options like checking roles for other account IDs or displaying policies for specific role ARNs, but I decided against it.

My motivation for creating canido was simple: "I want to know what my current account can do." Checking other accounts or roles fell outside that scope. The name "canido" itself comes from "Can I do?" - focusing on your own capabilities, not others'.

--short Option

When you have many IAM roles or a single role contains numerous policies, the output can get long and hard to read. To address this, I added a --short option that displays only the names of attached IAM roles:

❯ canido --short
--- Checking AWS credentials ---
Target role: AWSReservedSSO_CanidoInlinePolicy_f1d7ab46757a3473

==================================================
  1. Managed Policies
==================================================
IAMFullAccess

==================================================
  2. Inline Policies
==================================================
AwsSSOInlinePolicy

Distributed via Homebrew

Since I'm a Mac user, I wanted to distribute canido via Homebrew. This was my first time distributing a tool through Homebrew, so it involved a lot of research and trial and error.

To distribute a package via Homebrew, you typically need to add it to the official homebrew/core repository. This requires meeting certain criteria, including being open source and having some level of popularity (like GitHub stars).

For lesser-known tools like canido, getting into core is a high bar. Instead, I used the "tap" feature, which allows anyone to distribute packages without going through the review process. The trade-off is that users need to add one extra line to tap the repository before installing:

brew tap tttol/tap # Add the tap
brew install canido # Install canido

Wrapping Up

I hope canido becomes useful for AWS users out there. If you find it helpful, please give it a star on GitHub!

Developing an app for household management with AWS Amplify

Toru Takahashi — Tue, 20 Aug 2024 02:25:02 +0000

Introduction

Hi everyone.

In this article, I’m going to introduce the household budgeting app I’ve developed and currently operate using AWS Amplify (referred to as "Amplify" from here on).

🚨Please note, this app is a personal project and is not intended for commercial use. It’s designed solely for use by my family and me.🚨

💡Original japanese post is here.(I wrote this too)💡
https://qiita.com/tttol/items/d79b5e67de4c33e27858

Intended Audience

Anyone looking to solve problems using web applications
Those who have heard of Amplify but don’t know the details
People who want to develop web applications using AWS resources easily
Those with app development knowledge but who are less confident in infrastructure

The problem of household management

“Our problem: Eliminating the hassle of reimbursements between family members”

My wife and I often talk about reimbursements. For example, if she goes shopping at the grocery store, she might temporarily cover the cost, and later I’ll pay her back for half of it.

Wife: “I went shopping and covered the cost, so please pay me back later.”
Me: “Thanks. Oh, by the way, I bought tissues at the pharmacy yesterday, so I’d like to offset that cost.”
Wife: “Hmm, but I’m planning to go to the store tomorrow, so maybe we can include that too…”
Me: “Ugh…” (This is where I get tired of thinking about it.)

Doing these reimbursements every day is a hassle, so I wanted a way to manage these situations better. The first method I thought of was using Google Spread Sheets.

Both my wife and I would record the amounts and items we paid for, and we’d use a SUMIF function in the last row to calculate the final amount each of us needs to pay. We didn’t need to settle the balance daily; we could do it weekly or monthly.

By sharing this spreadsheet between us, we aimed to make managing reimbursements easier.

Issues with Spreadsheet Management

Although managing things through a spreadsheet made the process somewhat easier, new issues arose.

It’s hard to enter data into the spreadsheet from a smartphone
- When entering data while out, you have to use the mobile app version of Google Spread Sheets.
- The screen is small…
- Data entry becomes a hassle, and receipts start piling up.
When the table fills up, you need to add more rows, which is also hard on a smartphone.
- As rows increase, scrolling becomes necessary.
It’s hard to see at a glance how much you owe.

As a result, I ended up doing most of the data entry on a PC at home when I had free time.

To solve these issues, I decided to turn the functionality of the spreadsheet into a web application.

Turning It into an App with Amplify

I built the application with Next.js and deployed it using Amplify Hosting.

The SUMMARY section at the top of the screen shows each person’s debt.

The area below that shows a list of items that have been reimbursed. You can see that two items, buy grocery and tissue, have been entered. Based on these two items, the app calculates that the husband owes nothing, while the wife has a debt of 1,051 yen. (The method for calculating debt will be explained later.)

You can add new items from the screen.

By improving the usability of the item creation screen, I addressed the issues with smartphone operation mentioned earlier. Dropdowns are used for label selection, a date picker for entering dates, and radio buttons for selecting the payer, making the interface more user-friendly.

How Debt is Calculated

It's hard to see at a glance how much you owe.

To address the issue mentioned above, the app displays a summary of each person’s debt at the top of the screen. This allows you to see your outstanding balance at a glance when you open the app.

The summary displays two items: Total NET debt and debt.Here’s what each of these represents:

Total NET debt – This shows the final amount one person owes after subtracting mutual unpaid amounts.
debt – This shows the total unpaid amount for each person before any offsets.

Let’s look at a specific example.

In the image, the husband has already covered 2,500 yen, while the wife has covered 398 yen. The husband needs to pay the wife half of 398 yen, which is 199 yen. The wife needs to pay half of 2,500 yen, which is 1,250 yen. These two amounts are shown under debt.

Subtracting these two values gives 1,250 - 199 = 1,051, meaning the wife ultimately owes the husband 1,051 yen.

Therefore, the Total NET debt is 0 yen for the husband and 1,051 yen for the wife.

	debt	Total NET debt
Husband	¥199	¥0
Wife	¥1,250	¥1,051

App Architecture

The architecture of the app is as follows. For those familiar with Amplify, this setup should be quite familiar.

Hosting

I use Amplify Hosting. Under the hood, S3 and CloudFront are used to deliver the HTML content.

The S3 bucket and CloudFront distribution used here cannot be viewed or edited. It seems that these resources are managed internally by AWS.

Database & API

I use DynamoDB as the database, where I store the items each person has paid for. CRUD operations are performed using AppSync with GraphQL.

In Amplify, a file called amplify/data/resource.ts is automatically generated, where you can define the DynamoDB architecture as IaC (Infrastructure as Code).

import { a, defineData, type ClientSchema } from '@aws-amplify/backend';

const schema = a.schema({
  Todo: a.model({
      content: a.string(),
      isDone: a.boolean()
    })
    .authorization(allow => [allow.group('Admin')]), // User-group based data access
});

// Used for code completion / highlighting when making requests from frontend
export type Schema = ClientSchema<typeof schema>;

// defines the data resource to be deployed
export const data = defineData({
  schema,
  authorizationModes: {
    defaultAuthorizationMode: 'apiKey',
    apiKeyAuthorizationMode: { expiresInDays: 30 }
  }
});

As mentioned at the beginning, this app is only used by my wife and me, so proper access control for viewing and editing app data is essential. In data/resource.ts, I’ve set up access controls so that only users in a specific user group on Cognito can access DynamoDB. The relevant part is as follows:

const schema = a.schema({
  Todo: a.model({
      content: a.string(),
      isDone: a.boolean()
    })
    .authorization(allow => [allow.group('Admin')]), // User-group based data access
});

The .authorization(allow => [allow.group('Admin')]), ensures that only users in the Admin group have access. (The Admin group is manually created in Cognito via the AWS Management Console beforehand.)

References:
https://docs.amplify.aws/react/build-a-backend/data/set-up-data/
https://docs.amplify.aws/react/build-a-backend/data/customize-authz/user-group-based-data-access/

Auth

Cognito is used for authentication.

Similar to the database, a file called amplify/auth/resource.ts is automatically generated, where you can define the authentication architecture.

import { defineAuth } from "@aws-amplify/backend"

/**
 * Define and configure your auth resource
 * @see https://docs.amplify.aws/gen2/build-a-backend/auth
 */
export const auth = defineAuth({
  loginWith: {
    email: true,
  },
})

References:
https://docs.amplify.aws/react/build-a-backend/auth/set-up-auth/

Operating Costs

Amplify is billed on a pay-as-you-go basis.

https://aws.amazon.com/jp/amplify/pricing/

The operating cost of my household budgeting app is about 100 ~ 200 yen (≒ $1 ~ $1.5)per month. Since the active users are just my wife and me, it’s practically free.

Conclusion

Managing our budget with the app has become much easier compared to using a spreadsheet. The app still has some rough edges, and I occasionally find bugs, so I plan to maintain it at my own pace.

Journey to Creating and Publishing a Custom CLI Command in Go

Toru Takahashi — Mon, 15 Jul 2024 02:27:46 +0000

💡Original japanese post is here.
https://zenn.dev/tttol/articles/c7dfc74d27e45d

Introduction

I implemented a CLI command in Go and published it on GitHub.

https://github.com/tttol/mergectl

It's called mergectl. You can use mergectl by downloading the binary with curl and saving it to /usr/local/bin. In this article, I’ll document the journey of implementing, publishing, and distributing a CLI command in Go as a reference.

Explanation of `mergectl`'s Functionality and Development Background

Before diving into the main topic, let me explain the functionality and development background of mergectl.

Functionality

mergectl is a command to merge multiple git branches at once.

For example, let's assume we have the following branch structure.

In my work, we often develop multiple versions in parallel, cutting the v1 branch from the main branch and the v2 branch from the v1 branch.

Any changes pushed to v1 need to be reflected in v2 as well. This means that we need to regularly merge v1 into v2. While this is a simple task of executing git merge remotes/origin/v1 on the v2 branch, the number of commits pushed to v1 and v2 by the development team makes manual merging cumbersome.

With mergectl, you can merge v1 into v2 by simply running mergectl exec v1 v2 in the directory where the git repository is cloned.

Similarly, if there are changes in the main branch due to a hotfix, you can reflect those changes in the v1 and v2 branches by running mergectl exec main v1 v2.

mergectl exec [source branch] [target branch 1] [target branch 2] [target branch 3] ...

Development Background

mergectl was originally a logic that I ran with a shell script. I had set up the following shell script to run regularly on my PC.

# merge main into v1
git checkout v1
git pull
git merge remotes/origin/main --no-ff
git push

# merge v1 into v2
git checkout v2
git pull
git merge remotes/origin/v1 --no-ff
git push

While this shell script was functioning well, it became cumbersome to change branch names within the script whenever a new version like v3 or v4 was introduced. Manually updating the script posed a risk of mixing up source and target branches.

This is where the idea of creating a CLI command came from, to simplify these tasks.

Library for CLI Command Development - Cobra

Now, let’s get into the main topic.

One way to implement a CLI command in Go is to use a library called Cobra.

https://github.com/spf13/cobra

Cobra is a library that supports and accelerates the implementation of CLI applications. For detailed usage, please refer to the documentation.

Since Cobra is implemented in Go, you can easily install it with the following command:

go get -u github.com/spf13/cobra@latest

With Cobra, you can easily implement the mergectl command as follows:

func main() {
    cmd.Execute()
}

package cmd

import (
    "fmt"
    "os"

    "github.com/spf13/cobra"
)

var rootCmd = &cobra.Command{
    Use:   "mergectl",
    Short: "USAGE: mergectl [source branch] [target branch]",
    Long:  `mergectl is a tool of "git merge". This command merges multiple git branches.`,
    Run: func(cmd *cobra.Command, args []string) {
        fmt.Println("Hello mergectl!")
    },
}

func Execute() {
    if err := rootCmd.Execute(); err != nil {
        fmt.Println(err)
        os.Exit(1)
    }
}

$ mergectl
Hello mergectl!

With this, we have created a CLI command that returns "Hello mergectl!" when executed.

Additionally, you can implement subcommands as well. By implementing the following version.go, running mergectl version will return the version of the CLI.

package cmd

import (
    "fmt"

    "github.com/spf13/cobra"
)

var Version string

var versionCmd = &cobra.Command{
    Use:   "version",
    Short: "Print the version number of mergectl",
    Run: func(cmd *cobra.Command, args []string) {
        fmt.Println("mergectl version:", Version)
    },
}

func init() {
    rootCmd.AddCommand(versionCmd)
}

$ mergectl version
1.0.0-rc

You can add the subcommand defined with var versionCmd to the root with rootCmd.AddCommand(versionCmd). How the value is assigned to var Version string is explained in the next chapter.

Managing Application Version

The version value is assigned to var Version string in version.go. The assignment is specified during the build process with the following command:

go build -ldflags "-X main.version=1.0.0"

You can receive the value of main.version in main.go as var version. Once received in main.go, you can pass this value to var Version string in version.go and display it appropriately.

Library for Release

Next, I’ll explain the release process.

GoReleaser

The created CLI command is distributed as a binary file. For creating the binary, we use GoReleaser.

https://goreleaser.com/

For detailed usage, please refer to the documentation.

GoReleaser manages release settings with a .goreleaser.yml file. You can automatically generate this yml file by running goreleaser init.

In my case, I used the generated yml file with minimal modifications. The parts I modified are as follows:

Changes in .goreleaser.yml

builds:
  - ldflags:
      - -s -w
      - -X main.version={{ .Version }}
    # Omitted
  flags:
    - -trimpath

-ldflags "-X main.version={{ .Version }}"
- This option sets the application version as explained earlier.
-s
- Strips debug information.
-w
- Strips debug information.

Reference Link

https://qiita.com/ssc-ynakamura/items/da37856f7f217d708a07

Conclusion

The mergectl I created is available as OSS, so feel free to use it according to the license.

Boost Your Development Efficiency! Simulate S3 with a Custom Amazon S3 Mock Application

Toru Takahashi — Wed, 10 Jul 2024 23:23:16 +0000

💡Original japanese post is here.
https://zenn.dev/tttol/articles/13032ef69d8333

Introduction

I've developed a mock application for Amazon S3 called "MOS3" (pronounced "mɒsˈθri"). Similar to LocalStack, MOS3 is an S3-like application that runs in a local environment.

MOS3 is a GUI application that allows you to manage files directly from your browser. You can upload files without having to use CLI commands like aws s3 cp.

Moreover, MOS3 can handle S3 requests from the AWS SDK, making it possible to simulate S3 operations locally.

You can find the source code here:
https://github.com/tttol/mos3

Background

I am an application engineer, and I frequently develop web applications using Java and other technologies.

Many of the applications I create use S3 as external storage, and it's often necessary to connect to S3 even for local development. While I sometimes use a development AWS account with actual S3 buckets, setting up an account can be cumbersome for small-scale applications. In such cases, I've used LocalStack as a mock for S3.

LocalStack is an excellent and convenient open-source software, but I have noticed some challenges:

It's primarily operated via CLI, making GUI-based file management difficult.
- There is a GUI feature, but it didn't meet my requirements.
LocalStack provides resources beyond S3, but I rarely need anything other than S3, making it overly complex for my needs.

Given these challenges, I thought, "Why not create something that perfectly fits my needs?" And thus, MOS3 was born.

Features

Use as a Local Replacement for S3

MOS3 runs at http://localhost:33333/s3.
※ For detailed installation instructions, please refer to the README.

MOS3 can be used as a standalone S3-like local file server, but it also accepts requests from the AWS SDK. For example, if you send a request using the getObjects method from the AWS SDK for Java, MOS3 will respond with the specified key's object.

To call MOS3 from the AWS SDK for Java, you need to set the endpoint of the S3Client to http://localhost:3333. Here’s a code sample:

S3Client s3 = S3Client.builder()
        .region(region)
        .endpointOverride(new URI("http://localhost:3333"))
        .build();

Caution

When specifying localhost as the endpoint, you may need to enable path-style access for it to work correctly.

S3Configuration s3Configuration = S3Configuration.builder()
        .pathStyleAccessEnabled(true) // enable path style access
        .build();

S3Client s3 = S3Client.builder()
        .region(region)
        .endpointOverride(new URI("http://localhost:3333"))
        .serviceConfiguration(s3Configuration)
        .build();

File Management via Browser

MOS3 allows you to manage files and directories through your browser.

You can upload files by clicking the "New File" button.

You can create new directories by clicking the "New Dir" button.

You can download files by clicking on them.

You can delete files or directories by clicking the trash can icon on the right.

Linking with Your Local PC Directory

docker run -p 3333:3333 -v ./upload:/app/upload -it --rm tttol/mos3:latest

The above is the command to run MOS3. (Quoted from the README)
MOS3 runs on a Docker container.

The key point here is the use of the -v option to mount the volume. Files uploaded to MOS3 are internally stored in the /app/upload directory. By mounting it with -v ./upload:/app/upload during container startup, files on MOS3 are synchronized with the ./upload directory. Therefore, you can manage MOS3 files directly from Mac Finder or Windows Explorer.

Future Features

MOS3 is still a work in progress. Below are some of the features I plan to implement in the future.

Handling Requests from AWS SDKs Other Than Java

I often use Java, so I have mainly implemented support for requests from the AWS SDK for Java. However, the behavior with other SDKs is not guaranteed, as some work and others do not. I plan to extend support to other SDKs in the future, but this remains a future task.

Handling AWS CLI Requests

Handling AWS CLI requests for commands like ls, mb, cp, and rm is still a work in progress. While ls and cp are minimally supported, handling other commands is a future task.

Conclusion

MOS3 is open-source software (MIT License). Issues and pull requests are welcome.
I will continue to improve MOS3 to make it an even more user-friendly application.

Forem: Toru Takahashi

Listing IAM Roles for Your Current AWS Account

Introduction

I Built a CLI Tool to List IAM Roles

Design Decisions

Focused on the Essentials

--short Option

Distributed via Homebrew

Wrapping Up

Developing an app for household management with AWS Amplify

Introduction

Intended Audience

The problem of household management

Issues with Spreadsheet Management

Turning It into an App with Amplify

How Debt is Calculated

App Architecture

Hosting

Database & API

Auth

Operating Costs

Conclusion

Journey to Creating and Publishing a Custom CLI Command in Go

Introduction

Explanation of mergectl's Functionality and Development Background

Functionality

Development Background

Library for CLI Command Development - Cobra

Managing Application Version

Library for Release

GoReleaser

Changes in .goreleaser.yml

Conclusion

Boost Your Development Efficiency! Simulate S3 with a Custom Amazon S3 Mock Application

Introduction

Background

Features

Use as a Local Replacement for S3

Caution

File Management via Browser

Linking with Your Local PC Directory

Future Features

Handling Requests from AWS SDKs Other Than Java

Handling AWS CLI Requests

Conclusion

Explanation of `mergectl`'s Functionality and Development Background