Implement a complete Identity and Access Management (IAM) strategy using Linux users, groups, and sudo policies. Configure SSH key-based authentication, manage secrets securely, enable audit logging, and enforce encryption — building a security posture equivalent to cloud enterprise security standards.
Cloud security is not a single wall — it is multiple overlapping layers of protection. If an attacker defeats one layer, the next layer stops them. This is called "defense in depth." In this project, you will implement all key layers: identity (who you are), access control (what you can do), encryption (protecting data), secrets management (protecting credentials), and audit logging (knowing what happened).
In cloud platforms, IAM (Identity and Access Management) controls who can access what resources. AWS IAM has Users, Groups, and Policies. Azure AD has Users, Groups, and Role Assignments. Linux has the same concept: users, groups, and sudo policies. The principle is identical — the implementation differs slightly.
| User | Role / Group | Permissions | Cloud Equivalent |
|---|---|---|---|
| cloudadmin | sudo | Full system access | AWS Root / Global Admin |
| webdev | webteam | Read/write web files only | Developer Role |
| dbadmin | dba | Database access only | DB Administrator Role |
| devops | devops,docker | Docker + deployments | DevOps Engineer Role |
| auditor | readonly | Read logs and configs only | Security Auditor Role |
/etc/group file stores the group database — checking it confirms the groups exist. This mirrors how cloud IAM groups are created before users are assigned to them.useradd command creates a new user. Breaking down the flags: -m creates a home directory (/home/username/), -s /bin/bash sets bash as the default shell, -G groupname adds the user to supplementary groups, -c "description" adds a comment (full name or role). The chpasswd command sets passwords for multiple users from stdin. The cut command extracts specific fields from /etc/passwd to verify user creation. Notice the devops user is added to the docker group — this gives permission to run Docker without sudo, exactly as you did for your main user in Project 3.visudo command safely edits sudo configuration files — it checks for syntax errors before saving, preventing a corrupted sudoers file that would lock you out of administrative access. We use -f /etc/sudoers.d/abc-retail to create a separate file for ABC Retail's policies (rather than editing the main /etc/sudoers), following the modular configuration best practice.%devops format means "the devops GROUP". NOPASSWD: allows these specific commands without re-entering a password. ALL=(ALL) means "on all hosts, as any user". Notice the DBA team can restart MariaDB and run mysqldump but cannot touch the web server or Docker. An auditor can only read logs — they cannot modify anything. This directly corresponds to how AWS IAM policies grant specific action permissions on specific resources.Password-based SSH authentication is vulnerable to brute-force attacks — automated tools can try millions of passwords per minute. SSH key-based authentication uses a cryptographic key pair: a public key (stored on the server) and a private key (kept securely on your laptop). Without the private key, access is impossible — this is equivalent to MFA because it requires something you HAVE (the key file) in addition to something you KNOW (the optional passphrase).
ssh-keygen command generates a cryptographic key pair. -t ed25519 specifies the Ed25519 algorithm — more secure and faster than the older RSA algorithm. -C "comment" adds an identifying comment to the public key. -f ~/.ssh/abc-retail-key specifies the output filename. After running this, you'll have two files: abc-retail-key (private key — NEVER share this) and abc-retail-key.pub (public key — this goes on the server). The passphrase adds an additional layer: even if someone steals the private key file, they need the passphrase to use it.~/.ssh/authorized_keys on the server. When you SSH to the server, it sends a cryptographic challenge that only the holder of the matching private key can answer. This eliminates the need for password authentication entirely. In AWS, you select an "EC2 Key Pair" when launching an instance — this is the same concept: AWS stores your public key and the instance uses it to authenticate your connections.-i flag specifies which private key to use. If you set a passphrase, you'll be prompted for it — this is the "something you know" factor. The server checks your key against authorized_keys — this is the "something you have" factor. Two factors = MFA. You should log in WITHOUT entering the server password. If you still see a password prompt, the key wasn't set up correctly.PasswordAuthentication no — disables password login entirely (key-only). PermitRootLogin no — the root user cannot log in via SSH at all (even with a key). If an attacker wants root access, they must first log in as a regular user and then use sudo. MaxAuthTries 3 — disconnect after 3 failed attempts (limits brute-force attacks). LoginGraceTime 20 — disconnect if the user hasn't authenticated within 20 seconds. These are the same settings enabled by default on AWS and Azure virtual machines.Secrets (passwords, API keys, database credentials) must never be stored in plain text files, code repositories, or environment variables in config files. HashiCorp Vault is the industry-standard secrets management tool — equivalent to AWS Secrets Manager or Azure Key Vault. You will run Vault locally in development mode to understand how it works.
VAULT_DEV_ROOT_TOKEN_ID sets a fixed root token for easy access). The --cap-add=IPC_LOCK flag allows Vault to lock memory pages, preventing the kernel from swapping sensitive data to disk — critical for a secrets manager. In production, Vault is run in HA (High Availability) mode with proper initialization and unsealing, but dev mode is sufficient for learning. Vault is available at http://[VM-IP]:8200.vault kv get command shows all stored keys in a secret path, proving the credentials are accessible but protected.Encryption protects data in two states: "at rest" (stored on disk) and "in transit" (traveling over the network). Cloud providers encrypt everything by default, but engineers must understand which encryption is in place and verify it is configured correctly.
.gpg file contains binary encrypted data — completely unreadable without the private key. The gpg --decrypt command uses the matching private key (stored in your GPG keyring) to decrypt the file. In production, the private key would be stored in a Hardware Security Module (HSM) or Vault, accessible only to authorized backup restoration processes.mysql_ssl_rsa_setup command generates the necessary SSL certificates. When the application connects with REQUIRE SSL in the connection string, all data transmitted between the web server and database is encrypted — preventing network interception attacks (man-in-the-middle). This is "encryption in transit."Audit logs record who did what, when, and from where. They are essential for security investigations ("who deleted those records?"), compliance audits (GDPR, PCI-DSS, SOC2), and detecting unauthorized access. Cloud services like AWS CloudTrail and Azure Monitor provide this — you will implement it manually to understand what information is captured.
/var/log/auth.log file records all authentication events: SSH logins (successful and failed), sudo commands, su (switch user) events, and PAM authentication events. Every entry includes a timestamp, hostname, process name, and details. This is your security event log — equivalent to AWS CloudTrail's "Who called what API and when?" This log is the first place security engineers check during an incident investigation.auditd) provides much more detailed logging than the standard auth.log. It can record every system call made to the kernel, including file reads/writes, process execution, and network connections. This is the equivalent of enabling AWS CloudTrail's detailed management events — it increases log volume but provides forensic-level detail for security investigations.auditctl -w rule watches a specific file or directory: -p wa logs write and attribute-change events, -p rwxa logs read, write, execute, and attribute changes. -k keyword adds a searchable tag to the event. These rules create audit trails for: changes to user accounts (/etc/passwd), privilege escalation changes (/etc/sudoers), web file modifications, backup file access, and SSH configuration changes. If a security incident occurs, you can search for the specific audit key to see all relevant events.ausearch tool queries audit logs by key, timestamp, user, or event type. aureport generates summary reports. These tools turn thousands of raw audit log entries into actionable security intelligence — which users are making changes, how many failed login attempts occurred, which files are being accessed most frequently. This is equivalent to the query and analysis features of cloud security services like AWS GuardDuty or Azure Defender for Servers.