DEV Community: Khem Sok

a practical guide to understanding iam policies

Khem Sok — Wed, 28 Jun 2023 23:41:18 +0000

TLDR

AWS Identity and Access Management (IAM) policies regulate access to AWS resources. Policies can be attached to identities (users, groups, or roles) or resources. Each policy consists of statements with key elements: Principal, Action, Resource, Effect, and optional Conditions.

Policies can either be identity-based, attached to an IAM identity, or resource-based, attached directly to a resource. The policy defines permissions for an identity or specifies what actions a principal can perform on a resource.

Each policy statement has the following elements:

Principal: In identity-based policies, the principal is the attached IAM identity. In resource-based policies, the principal is an entity granted or denied access.
Action: Defines specific tasks that the policy allows or denies.
Resource: Specifies the AWS resource that the policy governs.
Effect: Can be Allow or Deny. If Allow, the principal is permitted to perform the action on the resource unless another policy denies it. If Deny, it overrides any Allow.
Condition (optional): Specifies any conditions for the policy statement to take effect.

Policies are evaluated as follows: an explicit Deny overrides any Allow. If there's no explicit Deny, an explicit Allow permits the request. If neither Allow nor Deny is present, the request is denied by default.

Principals in a policy can be of different types, including AWS for IAM users or roles, Service for AWS services, Federated Users for federated identities, Anonymous for unauthenticated access, and AWS Organizations for the entire organization or an organizational unit (OU).

The blog post includes numerous examples of IAM policies with different conditions, multiple principals, and different principle types to demonstrate the flexibility and complexity of IAM policy creation. Remember, the key rule in IAM policy creation is to grant the least amount of access necessary.

Introduction

AWS Identity and Access Management (IAM) policies are the cornerstone of managing access to AWS resources. A policy is an entity that, when attached to an identity or resource, defines their permissions. This blog post will help you understand the core components of IAM policies and the pivotal role they play in AWS's access control capabilities.

Understanding IAM Policy Types

There are two main types of IAM policies:

Identity-based policies: These policies attach to an IAM identity (a user, group, or role). They control what actions the identity can perform, on which resources, and under what conditions.
Resource-based policies: These policies attach directly to a resource. They define what actions a specified principal (which could be in another account) can perform on that resource.

Deep Dive into IAM Policy Components

IAM policies are composed of one or more statements, and each statement includes these elements:

Principal: In an identity-based policy, the principal is the IAM identity to which it's attached. In a resource-based policy, the principal is the entity that is allowed or denied access to the resource. The principal can be specified as a single string or a list of strings.
Action: This is the specific task the policy allows or denies. For instance, s3:PutObject permits an entity to upload an object to an S3 bucket. Actions can be specified as a single string or a list of strings.
Resource: The resource is the specific AWS asset that the policy allows or denies actions upon. Resources are defined using Amazon Resource Names (ARNs), and can be specified as a single string or a list of strings.
Effect: The effect can be either Allow or Deny. If the effect is Allow, the principal is permitted to perform the action on the resource, assuming no other policies deny it. If the effect is Deny, it overrides any Allow.
Condition: The condition is an optional field specifying any conditions for the policy statement to take effect. Conditions might include IP address range, time of day, whether MFA is enabled, and more.

IAM Policy Evaluation Logic

IAM employs the following logic to evaluate policies:

An explicit Deny in any policy trumps any Allow.
If there's no explicit Deny, an explicit Allow in any policy permits the request.
If neither Allow nor Deny is present, the default decision is to deny the request.

Examples of IAM Policies

Example 1: IAM policy that includes a list for each of these elements:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ExampleStatement",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::123456789012:user/Alice",
                    "arn:aws:iam::123456789012:user/Bob"
                ]
            },
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::my_bucket/example1",
                "arn:aws:s3:::my_bucket/example2"
            ]
        }
    ]
}

This policy grants both Alice and Bob the ability to upload, download, and delete the example1 and example2 objects in my_bucket.

Example 2: Allow Access Only From Specific IP Addresses

The following IAM policy allows the principal to perform any Amazon S3 action (s3:*) on the bucket named my_bucket but only if the request originates from the range of IP addresses specified in the condition:

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": "s3:*",
        "Resource": "arn:aws:s3:::my_bucket/*",
        "Condition": {
            "IpAddress": {
                "aws:SourceIp": "192.0.2.0/24"
            }
        }
    }
}

In this policy, the aws:SourceIp condition key is used to match the IP address from where the request originates.

Example 3: Allow Access Only During Specific Times

The following IAM policy allows the principal to perform any Amazon DynamoDB action (dynamodb:*) but only during a specific time of day:

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": "dynamodb:*",
        "Resource": "*",
        "Condition": {
            "DateGreaterThan": {
                "aws:CurrentTime": "09:00:00Z"
            },
            "DateLessThan": {
                "aws:CurrentTime": "17:00:00Z"
            }
        }
    }
}

In this policy, the aws:CurrentTime condition key is used to allow requests only between 09:00:00 UTC and 17:00:00 UTC.

Example 4: Allow Access Only With MFA

This IAM policy allows deleting an Amazon S3 bucket (s3:DeleteBucket) but only if the requester is using multi-factor authentication (MFA):

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": "s3:DeleteBucket",
        "Resource": "*",
        "Condition": {
            "Bool": {
                "aws:MultiFactorAuthPresent": "true"
            }
        }
    }
}

In this policy, the aws:MultiFactorAuthPresent condition key is used to check whether the request was made using MFA.

Remember, conditions provide an additional layer of security to control when and who can use the actions granted in your IAM policies. By understanding and leveraging conditions, you can greatly enhance the security of your AWS resources.

A Note on IAM Principles

In an AWS IAM policy, the Principal element identifies the user, account, service, or other entity allowed or denied access to a resource. Here are different types of principals:

AWS: Specifies an AWS account, IAM user, IAM role, federated user, or assumed-role user.
Service: Allows AWS services to act on a resource.
Federated Users: Used for identities federated into AWS.
Anonymous: The wildcard "*" allows unauthenticated access.
AWS Organizations: Specifies the entire organization or an organizational unit (OU).

Remember to grant only the minimum necessary permissions to maintain security.

Examples

Example 1: AWS Principle

This is a resource-based policy that grants an IAM user in another AWS account the permission to read objects from an S3 bucket:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "GrantReadAccess",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:user/Alice"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::my_example_bucket/*"
        }
    ]
}

Example 2: Service Principle

This is a resource-based policy that allows the EC2 service to assume a role:

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Principal": {
            "Service": "ec2.amazonaws.com"
        },
        "Action": "sts:AssumeRole"
    }
}

Conclusion

IAM policies form the backbone of AWS's access control capabilities. They can be complex, so taking the time to understand the different elements and principles is essential for managing AWS resources securely and effectively. Always remember the guiding rule of granting the least amount of access necessary to perform a function. It's a crucial step in maintaining the security of your AWS infrastructure.

automate notion and todoist: a guide to syncing your to-do list with lambda and webhooks 🔥

Khem Sok — Mon, 24 Apr 2023 01:39:51 +0000

Introductions 👨‍💻

I use Notion to keep track of all my todos inside of a database. However, if you’re on your phone, Notion doesn’t provide an easy way for user to easily add todos into the database without clicking multiple things and the loading takes annoyingly forever. This is where Todoist comes in. I can easily click on the app and press the plus button and it will create a todo for me. However, I don’t want to use two applications to track the same thing, so I wanted to sync my Todoist with Notion.

I see that there are automations existed already with applications like Zapier but there are limitations to it. So I thought I could go ahead and automate the system myself. And this blog aims to help out others who want to do the same.

Requirements

You will need to have an AWS account for this tutorial as we will be creating a Function URL with AWS Lambda. (Don’t worry it won’t cost you anything, you will not exceed the Free Tier)

Todoist and Notion both have APIs that we can use have them sync with each and it is not hard to work with at all.

Step 1

Head to Notion API and create a new integration: https://www.notion.so/my-integrations

Step 2

Copy the Internal Integration Token

Step 3

Copy the Notion Database ID that you want to create the task in. You can get the Notion Database ID by heading to Notion online and view the database as a full page and in the URL, you will see the database ID.

Step 4

You need to allow your database to connect with the Notion Integration that we just created

Step 5

Head to AWS console and Create a Python Lambda Function

Make sure to choose Python 3.9

Step 6

Create Function URL and select Auth type as NONE

Step 7

Add Layer to the Lambda

Step 8

Copy the following code. You will need to change three things

Add the Internal Integration Token
Add the Notion Database ID
Add the field name of your database where you want the task name to be. E.g Name

Then deploy it.

import json
import requests

url = "https://api.notion.com/v1/pages"
headers = {
    "Authorization": "Bearer <Internal Integration Token>",
    "Content-Type": "application/json",
    "Notion-Version": "2022-06-28"
}

def lambda_handler(event, context):
    content = json.loads(event['body'])['event_data']['content']

    data = {
        "parent": {
            "type": "database_id",
            "database_id": "<Notion Database Id>"
        },
        "properties": {
            "<field name your database for title>": {
                "type": "title",
                "title": [
                    {
                        "type": "text",
                        "text": {
                            "content": content
                        }
                    }
                ]
            }
        }
    }


    response = requests.post(url, headers=headers, data=json.dumps(data))

    return {
        'statusCode': 200,
        'body': 'success',
    }

What we have done so far is create a Lambda Function that will create an item in the database whenever it gets called by Todoist Webhook.

Now we have to configure Todoist for it to make a make a request to that Function whenever there is a new item created.

Step 9

Head to Todoist Developer console to create a new app: https://developer.todoist.com/appconsole.html

Step 10

Go back to our Lambda and copy our Function URL. Paste it in the Webhook callback url in Todoist App. Also select the item:added Watched Events. Then click on Activate webhook.

Step 11

So Webhook doesn’t activate by default until we complete OAuth process with the account. For more information here: https://developer.todoist.com/sync/v8/#webhooks

First add the OAuth redirect URL as our Function URL in the Todoist App

Now to complete the OAuth process for the account. Below are two CURL command, but you can do it with Postman or other HTTP clients as well.

curl "https://todoist.com/oauth/authorize?client_id=<client_id>&scope=data:read&state=secretstring"

Click on the link and follow the instruction and it should redirect you to the Function URL. DO NOT close out of this tab as the URL will have the code that we need.

curl "https://todoist.com/oauth/access_token" \
    -d "client_id=<client_id>" \
    -d "client_secret=<client_secret>" \
    -d "code=<code received from the first curl command>" \
    -d "redirect_uri=<function url>"

That is all. Now whenever you create an item inside of your Todoist, it will create a row inside of your Notion database.

Conclusion 🎯

Hope this helps you guys out. Let me know if you have any questions ✌️

how taking cold shower everyday landed me amazon and microsoft offers 👨‍💻

Khem Sok — Sun, 12 Mar 2023 18:40:17 +0000

this is not an article articulating the technical details of how i prepared for my microsoft and amazon interview, but rather how i built the necessary habits and mindset going into my preparation.

as you are reading this, you may be thinking to yourself, how does taking a cold shower have anything to do with getting a tech job offer. in my case, it played a major role. the action of taking a cold shower itself does not directly influence my success during the interview itself, however, it impacted on a larger scale which is the foundation on how i was able to build up a mindset that allows me to go about executing a routine that i had to follow on a daily basis leading up to the interview. that directly influenced how i was able to successfully construct a plan, act on it, and lead me to acing the interviews.

“preparation are keys”

i hate the cold and the feeling of being cold. i am the type of person that has a space heater nearby and uses a hand warmer at the office. i very much despise and detest cold showers. so this begs the question of why do it? for the simple reason, to make myself uncomfortable. after i finished reading can’t hurt me and man’s search for meaning, i just spontaneously decided one night that i am going to take a cold shower.

“do the things you don’t like” - david goggins

i remember the first time thinking that it was not too bad. although, while in the shower, i was shaking uncontrollably and afterward i had cold feet for hours. but i remember thinking it was not too bad. the feeling of accomplishment of doing something difficult was enough to combat the uncomfortableness. i kept at it, once in the morning and once at night. gradually, i increased the time i stayed in the shower from 5 minutes all the way to 10 minutes in the first week. the first few days went well, i was actually excited to do this task because the dopamine afterward was worth it. however after the first week, the task started to become increasingly more cumbersome and it dawned on me that i do not want to be doing this. the fear of taking cold showers starts to creep in as my mind poisons with the thought of having to stand through the freezing cold droplets of water for 10 minutes. delaying, stalling, procrastinating became the name of the game. i would stand in front of my shower door for minutes thinking why the hell am i doing this. i absolutely hated it. i hate being cold during it and afterward. all these thoughts would run through my brain, but i do it anyway. every single time for the first 2.5 months, i would question myself “why am i doing this? i could be enjoying a hot shower right now”, but once i set the timer on my phone, i immediately jump into the shower and go through the ordeal. and every single time i got out of it feeling accomplished. this one small change that i added to my routine helps establish the foundation of how i go about building up my discipline.

“consistent actions everyday will lead to result overtime”

building habits are very difficult. you can be very motivated to go to the gym for the first few days, but over time that motivation dissipates. when that happens, what is there to rely on? discipline. that is the lesson that i’ve learnt from taking cold showers everyday. the understanding that no matter how annoying and uncomfortable the task of a cold shower is i will do it anyway. that very thought process in itself is very powerful. the thing with discipline is it can be trained like a muscle. once your discipline muscle is leveling up, you are more inclined to do things that make you uncomfortable. this led me to discovering the “no days off” framework where there are certain things that i will do everyday no matter what. these include meditating (>5 mins), reading (25 mins), playing an instrument (25 mins), journaling (25 mins), planning the next day (25 mins) and studying (50 mins).

“think about how good you will get in 4-5 years if you were to do this task every single day no matter what”

once the routine had been established, it was not very hard to adapt it to preparing for the interview. with the new found mindset, i was more capable of handling difficult and complex tasks that i do not want to do. it helps me tremendously in persevering through failing to solve easy questions on leetcode in the first few weeks. no matter how hard it is, i told myself i will have to spend x amount of minutes on it each day. i did not want to overwhelm myself too much so i started off at around 15 minutes. bit by bit, i started to see improvements in my ability to solve problems. as the problems get easier, i started to increase the intensity of my routine as i need to go wide and try to solve as many problems as i can to spot the different patterns. solving technical coding challenges is just one aspect of the interview, but the same concepts applied to those other areas as well. my after work hours and weekends were consumed with my preparation. every day, week, and month was planned out on what areas and materials that i need to be focusing on. this allows me to have a clear picture of what i need to be doing at all times so i won’t waste time thinking about what i need to do.

“1% improvement every single day will compound you to a 3800% improvement in one year. ”

you have to understand that you will not transform yourself overnight, it will take months, or maybe years. but understand this, if you keep at it and grind every single day, you will get to wherever you want to go. you have to trust the process and have the belief that what you are doing right now will lead you to your goal. visualize it, dream it, feel it.

i was not perfect along the way. there were days where i wasn’t being as productive as i would like to be. there were days where i did a problem just to say i did that problem. there were a lot of days where i wasted time procrastinating. there were days where i wanted to take a break and quit the “no days off”. i am definitely still learning and trying to become better myself. i constantly have to remind myself that this is a marathon, not a sprint. you cannot rush this process. the one thing that helps keep me in check is to remember my goals and the why. understanding and remembering that i am on a journey to better myself is a refresher that i sometimes need to push myself to do my work out at 12 am in the morning or study for an extra pomodoro.

the lessons that i learnt along the way are huge. i get a sense that i understand myself better and the tendencies that i would partake in. for example, i’d get distracted by watching a youtube clip and i would go on a tangent for about 10-15 minutes before i realized that i need to stop and do the tasks that i set out for. things like that i would realize and find ways to combat it like using a blocker to block out sites during focus time. i started to see the tendency of my energy level during the day so i tried to maximize my time during those peak energy levels. it was definitely very fun to experiment with different routines such as eating habits, sleeping routine, and journal about it and see what i can do to tweak it to better maximize my productivity. and as i kept up with the routine every single day, i started to have this sense of belief that i’ll do very well in the interview. i wasn’t 100% confident going into the interview but i knew that with either outcome i was going to be fine with it because i did everything that i could to prepare for it.

in conclusion, i want to emphasize this point, i am not special by any means of the imagination. i truly believe anyone can absolutely do this. you have the power to change your life at this very second. create a plan, design a schedule and execute on it no matter what. every decision you make can steer you toward your goals. it’s hard, but not impossible. consistent hard work will get you to where you want to go, building that mindset is the goal. i hope you guys enjoy the article.

this article was written a while back when i first joined aws, but i just never posted it anywhere. thought to share my experience here : )

writing clean and maintainable code: best practices for developers 🦉

Khem Sok — Mon, 20 Feb 2023 00:06:30 +0000

intro

writing code is one thing, but writing clean and maintainable code is another. clean and maintainable code is essential for developing successful applications that are easy to maintain, improve, and scale over time. in this article, we'll cover some best practices for writing clean and maintainable code that you can use to take your development skills to the next level.

follow good naming conventions

the first step to writing clean code is to follow naming conventions. use meaningful and descriptive names for your variables, functions, and classes. avoid using abbreviations or acronyms unless they're widely recognized. use camelCase or snake_case for naming variables and functions, and use PascalCase for naming classes.

keep it simple stupid (kiss)

when writing code, keep it simple stupid. write code that is easy to understand and that is easy to read. avoid writing long and complex functions, which can be challenging to understand and maintain. if a function is too long, consider splitting it into smaller, more manageable functions.

dont repeat yourself (dry)

one of the most essential principles of writing clean and maintainable code is to avoid repetition. if you find yourself writing the same code in multiple places, consider extracting it into a separate function or class. this will not only make your code more concise, but it will also make it easier to maintain.

write tests

writing tests is an essential part of writing clean and maintainable code. ensure that your tests cover all the critical parts of your code, and that they're easy to understand and maintain.

refactor regularly

refactoring is the process of improving your code without changing its functionality. regularly refactoring your code ensures that it remains clean and maintainable over time. refactor long functions, remove redundant code, and improve variable names. this process will help keep your codebase up-to-date and ensure that it remains easy to maintain. always leave code better than when you found it

conclusion

writing clean and maintainable code is an essential skill for developers. following these best practices can help you to write code that is easy to understand, maintain, and scale over time.

mastering git: the only essential commands you need to know to be a productive developer [pt 2] 🔥

Khem Sok — Sun, 12 Feb 2023 02:27:47 +0000

intro

this article is pt 2 of the mastering git series. see part 1 here. in this article, we will expand on those commands and introduce 7 additional git commands that are useful to your workflow.

8 - `git status`

this command displays the status of your local repository, including the changes that have been staged, changes that have been made but not stage, and untracked file.

$ git status

9 - `git diff`

this command displays the difference between two snapshots of your repository. you can use it to see the changes you've made in your local repository compared to the remote repository, changes between different branches, or changes between different commits.

$ git diff HEAD # to compare the current branch with the latest commit

$ git diff branch1 branch2 # to compare two branches

10 - `git fetch`

this command is used to retrieve changes from a remote repository, but it does not integrate them into your local repository. you can use it to see what changes have been made to a remote repository without affecting your local copy of the project.

$ git fetch origin # to fetch changes from the "origin" remote repository

11 - `git stash`

this command is used to save changes that haven't been committed or staged to a temporary location. this can be useful if you need to switch to a different branch without having to commit.

$ git stash # to stash changes

$ git stash save "comment" # to save stash in the repository

$ git stash list # to list all stashes

$ git stash pop # to reapply previously stashed changes

12 - `git merge`

this command allows you to combine changes from different branches into a single branch.

$ git merge branch-name # to merge changes from a branch named "branch-name" into the current branch

$ git merge branch-name --squash # to merge changes from a branch named "branch-name" into the current branch without bringing in the commit

13 - `git log`

this command displays a log of all of the commits in your git repository. you can use it to see the history of your project and find specific commits

$ git log # to display the log of all commits

$ git log -5 # to display last 5 commits

14 - `git rebase`

this command allows you to reapply a series of commits from one branch onto another branch. this is useful for reorganizing the history of a branch to make it more readable.

$ git rebase origin main # to reapply the commits from the branch origin main onto the current branch

conclusion

here are additional seven git commands that is essential to your git workflow. hope you guys find this useful. thx.

mastering git: the only essential commands you need to know to be a productive developer [pt 1] 🔥

Khem Sok — Sun, 05 Feb 2023 21:28:25 +0000

intro

git is something all programmers have used or will use one way or another. with its vast number of commands and options, it can be overwhelming for someone that is just starting out. learn these few essential commands and you'll be 80% there with your journey with git.

1 - `git init`

this command is used initialize a new git repository. it creates a .git folder wehre all of the version control information is stored.

git init # to initialize a repository

2 - `git clone`

this command is used to clone an existing repository from a remote server to your local machine.

git clone https://github.com/user/repo.git # to clone a repository

git clone https://github.com/user/repo.git another-repo-name # to clone a repository and give it a different local name

3 - `git add`

this command is used to add changes to the staging area.

git add . # to add all changes in the current directory

git add file.txt # to add changes in a specific file

4 - `git commit`

this command is used to save changes to the repository. the changes can be a single file or multiple files. when you run git commit, you'll be prompted to write a commit message to describe the changes you've made.

git commit -m "commit message" # to commit changes with a message directly from the command line

git commit -a # to commit all changes in the repository

5 - `git push`

this command is used to push changes from your local to a remote repository.

git push origin main # to push changes to the remote repository named "origin" and the branch named "main"

git push -u origin main # to set the upstream branch for "origin/main" to "main"

6 - `git pull`

this command is used to retrieve changes from a remote repository and merge them into your local repository.

git pull origin main # to get changes from the remote repository named "origin" and the branch named "main"

git pull --rebase # to reapply your local changes on top of the changes in the remote repository

7 - `git checkout`

this command is used to switch between different branches in the repository. branches allow you to work on different version of the project.

git checkout -b new-branch # to create a new branch named "new-branch" and switch to it

git checkout branch-name # to switch to an existing branch named "branch-name"

conclusion

these are the seven essential git commands that you need to get started. mastering these command, and you'll be on your way to become a git expert.

DEV Community: Khem Sok

a practical guide to understanding iam policies

TLDR

Introduction

Understanding IAM Policy Types

Deep Dive into IAM Policy Components

IAM Policy Evaluation Logic

Examples of IAM Policies

A Note on IAM Principles

Examples

Conclusion

automate notion and todoist: a guide to syncing your to-do list with lambda and webhooks 🔥

Introductions 👨‍💻

Requirements

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Step 10

Conclusion 🎯

how taking cold shower everyday landed me amazon and microsoft offers 👨‍💻

writing clean and maintainable code: best practices for developers 🦉

intro

follow good naming conventions

keep it simple stupid (kiss)

dont repeat yourself (dry)

write tests

refactor regularly

conclusion

mastering git: the only essential commands you need to know to be a productive developer [pt 2] 🔥

intro

8 - git status

9 - git diff

10 - git fetch

11 - git stash

12 - git merge

13 - git log

14 - git rebase

conclusion

mastering git: the only essential commands you need to know to be a productive developer [pt 1] 🔥

intro

1 - git init

2 - git clone

3 - git add

4 - git commit

5 - git push

6 - git pull

7 - git checkout

conclusion

8 - `git status`

9 - `git diff`

10 - `git fetch`

11 - `git stash`

12 - `git merge`

13 - `git log`

14 - `git rebase`

1 - `git init`

2 - `git clone`

3 - `git add`

4 - `git commit`

5 - `git push`

6 - `git pull`

7 - `git checkout`