Access control is the same problem everywhere. Decide who gets in, and decide exactly what they can do once they are. Day 17 came at that idea from two directions, a Postgres database on Linux and an IAM group on AWS, and the shape underneath both is identical.
One Linux task, one AWS task. Install PostgreSQL, then create a database, a user, and grant that user access. On AWS, create an IAM group to manage permissions for a set of users at once. The tasks come from the KodeKloud Engineer platform.
PostgreSQL: a database, a user, and a grant
PostgreSQL runs its own user system, separate from Linux logins, and it operates as the postgres OS user. So you drop into its shell as that user:
# Log in as the postgres superuser
sudo -u postgres psql
From there, it is three statements: a database, a user with a password, and a grant that links them.
CREATE DATABASE my_database;
CREATE USER my_user WITH ENCRYPTED PASSWORD 'securepassword';
GRANT ALL PRIVILEGES ON DATABASE my_database TO my_user;
WITH ENCRYPTED PASSWORD stores a hash rather than the plain text, which is the difference between a password and a liability. The GRANT is what actually connects the user to the database.
Here is the part that catches people, and it caught me. GRANT ALL PRIVILEGES ON DATABASE does less than it sounds like. It grants database-level rights, connecting, creating schemas, and making temp tables. It does not grant access to the tables inside. For that, you need a second grant:
GRANT ALL ON ALL TABLES IN SCHEMA public TO my_user;
So "I granted the user everything" and "the user can actually read the tables" are two separate statements. Miss the second and your user connects fine, then cannot touch a single row, which is a confusing way to lose an afternoon. If you would rather stay out of the psql shell, createuser and createdb do the same job from the command line, and you set the password with ALTER USER afterwards.
IAM groups: manage permissions for people, not per person
On AWS, the task was an IAM group. Groups exist for the same reason grants do, managing access without repeating yourself. Attach a policy to five users one by one, and you now have five things to update every time the rules change. Attach it to a group, and you have one.
# Create the group
aws iam create-group --group-name Nautilus_Admin
# Confirm it exists
aws iam get-group --group-name Nautilus_Admin
aws iam list-groups
Creating the group is only the opening move. A group with no policy and no members does nothing at all. The next two commands are what make it useful, attaching a policy and adding people:
aws iam attach-group-policy --group-name Nautilus_Admin --policy-arn <policy-arn>
aws iam add-user-to-group --group-name Nautilus_Admin --user-name Bob
Two things worth knowing. A group is not an identity, you cannot sign in as a group, only as a user or a role. And groups do not nest, you cannot put a group inside another group. It is a flat container for users, and that is deliberate.
Same idea, two systems
Both tasks are access control wearing different clothes. Postgres asks who connects and what they can touch. IAM asks who you are and what you are allowed to do. The habit that carries across both is setting access at the level that scales, a grant on the right scope, a policy on the group instead of the individual. Do it, person by person, and it works right up until it becomes a mess nobody can audit.
So here is the Day 17 question. Would you rather set permissions once at the level that scales, or keep patching them one user at a time until you have lost track of who can do what?
Day 17 down. Eighty-three to go.
Top comments (0)