Stories by adarsh babu on Medium


<p>If you’ve ever set up a website or worked with online security, you’ve likely come across the term “SSL/TLS certificate.” These certificates are like digital passports that help secure communication between a website and its visitors by encrypting data. But not all certificates are created equal. Two common options you might encounter are <strong>self-signed certificates</strong> and <strong>Let’s Encrypt-signed certificates</strong>. So, what’s the difference, and why does it matter? Let’s break it down.</p>
<h4>What is a Self-Signed Certificate?</h4>
<p>A self-signed certificate is exactly what it sounds like: a certificate you create yourself. Think of it as a homemade ID card. Using tools like OpenSSL or other software, anyone can generate a self-signed certificate without needing approval from an outside authority. It still encrypts data — meaning it scrambles the information traveling between a server and a user — but it doesn’t come with a stamp of trust from a recognized third party.</p>
<p>Because you’re the one signing it, there’s no external verification of your identity or legitimacy. When someone visits a site using a self-signed certificate, their browser will usually throw up a big warning like “Connection Not Secure” or “Certificate Not Trusted.” This happens because the browser can’t confirm that the site is who it claims to be. For personal projects, testing environments, or internal systems where trust isn’t a concern, self-signed certificates can be a quick and free solution. But for public-facing websites? Not so much.</p>
<h4>What is a Let’s Encrypt Certificate?</h4>
<p>Let’s Encrypt, on the other hand, is a free, automated, and widely trusted service that provides SSL/TLS certificates. Launched in 2016 by a nonprofit called the Internet Security Research Group (ISRG), Let’s Encrypt works as a <strong>Certificate Authority (CA)</strong> — a trusted entity that issues certificates after verifying a domain’s ownership. When you use Let’s Encrypt, you’re getting a certificate that’s recognized by all major browsers, like Chrome, Firefox, and Safari.</p>
<p>To get a Let’s Encrypt certificate, you don’t sign it yourself. Instead, you prove to Let’s Encrypt that you control your domain (usually through an automated process), and they issue a certificate that’s valid for 90 days. After that, you can renew it — again, for free. Because it’s backed by a trusted CA, visitors to your site won’t see scary warnings, and your site will display that reassuring padlock icon in the browser.</p>
<h4>Key Differences</h4>
<p>Here’s a quick rundown of how self-signed and Let’s Encrypt certificates stack up:</p>
<ol><li><strong>Trust and Validation</strong></li></ol>
<ul>
<li>
<strong>Self-Signed:</strong> No external validation. You’re vouching for yourself, so browsers and users won’t trust it by default.</li>
<li>
<strong>Let’s Encrypt:</strong> Issued by a trusted Certificate Authority with domain verification, so it’s universally accepted.</li>
</ul>
<ol><li><strong>Cost</strong></li></ol>
<ul>
<li>
<strong>Self-Signed:</strong> Free to create using open-source tools.</li>
<li>
<strong>Let’s Encrypt:</strong> Also free, but with the added benefit of credibility.</li>
</ul>
<ol><li><strong>Ease of Use</strong></li></ol>
<ul>
<li>
<strong>Self-Signed:</strong> Simple to generate, but you’ll need to manually install it and deal with trust warnings.</li>
<li>
<strong>Let’s Encrypt:</strong> Automated tools (like Certbot) make it easy to install and renew, with no warnings for users.</li>
</ul>
<ol><li><strong>Use Cases</strong></li></ol>
<ul>
<li>
<strong>Self-Signed:</strong> Best for testing, development, or private networks where you control who accesses the system.</li>
<li>
<strong>Let’s Encrypt:</strong> Ideal for public websites, blogs, or any online presence where security and trust matter to visitors.</li>
</ul>
<ol><li><strong>Expiration</strong></li></ol>
<ul>
<li>
<strong>Self-Signed:</strong> You set the expiration date, which could be years in the future.</li>
<li>
<strong>Let’s Encrypt:</strong> Valid for 90 days, encouraging frequent renewals for better security.</li>
</ul>
<h4>Which Should You Choose?</h4>
<p>The choice depends on your needs. If you’re just experimenting with a local server or setting up something internal — like a company intranet where everyone knows to trust the certificate — a self-signed option might be fine. It’s quick, free, and gets the job done for encryption.</p>
<p>But if you’re running a website that interacts with the public — like an online store, a blog, or a portfolio — Let’s Encrypt is the way to go. Not only does it keep your visitors’ data safe, but it also builds trust. No one wants to shop on a site that triggers a “Not Secure” warning, right? Plus, with Let’s Encrypt being free and easy to automate, there’s little reason not to use it for anything public-facing.</p>
<h4>Final Thoughts</h4>
<p>Both self-signed and Let’s Encrypt certificates have their place in the world of online security. Self-signed certificates are a handy, no-cost tool for private or testing purposes, while Let’s Encrypt offers a trusted, user-friendly solution for the wider internet. For most people building a presence online, Let’s Encrypt is the clear winner thanks to its credibility and simplicity. Whichever you choose, securing your site with encryption is a step in the right direction — because in today’s digital world, safety matters.</p>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=707e20ce5e85" width="1" height="1" alt="">


Understanding the Difference Between Self-Signed and Let’s Encrypt Certificates


<p>Let’s walk through an example scenario that demonstrates how an IAM user, a role, and policies work together. In this scenario, we have a developer who normally has limited permissions but occasionally needs to perform administrative tasks. Rather than giving the developer full administrative privileges all the time, we create a role with elevated permissions that they can assume when needed.</p>
<h3>Example Scenario Overview</h3>
<ol><li><strong>IAM User (Developer):</strong></li></ol>
<ul>
<li>
<strong>Name:</strong> DevUser</li>
<li>
<strong>Access Type:</strong> Programmatic (via CLI/SDK) and/or Console access.</li>
<li>
<strong>Default Permissions:</strong> Limited access (e.g., read-only access to certain services).</li>
</ul>
<p><strong>2. IAM Role (Elevated Privileges):</strong></p>
<ul>
<li>
<strong>Name:</strong> AdminRole</li>
<li>
<strong>Attached Policy:</strong> Administrator-level permissions (e.g., using AWS managed policy AdministratorAccess).</li>
<li>
<strong>Trust Policy:</strong> Allows DevUser to assume this role.</li>
</ul>
<p><strong>3. Use Case:</strong></p>
<ul>
<li>DevUser operates with limited permissions by default.</li>
<li>When DevUser needs to perform tasks that require broader privileges, they assume AdminRole to temporarily receive administrator permissions via temporary security credentials.</li>
</ul>
<h3>Step-by-Step Example</h3>
<h3>1. Create the IAM User</h3>
<p>First, create the IAM user who will perform the day-to-day operations with limited permissions.</p>
<pre>aws iam create-user --user-name DevUser</pre>
<p>Then, create access keys for programmatic access:</p>
<pre>aws iam create-access-key --user-name DevUser</pre>
<p><em>Note:</em> Securely store the Access Key ID and Secret Access Key.</p>
<h3>2. Attach a Limited Policy to the User (or Group)</h3>
<p>You might attach a policy that only allows DevUser to perform basic operations (for example, read-only access to S3). This can be done directly or via an IAM group. Here’s an example of attaching the AWS managed policy for S3 read-only access:</p>
<pre>aws iam attach-user-policy \<br>  --user-name DevUser \<br>  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess</pre>
<h3>3. Create an IAM Role for Elevated Access</h3>
<p>Next, create a role that provides administrative permissions. This role will have a trust policy allowing DevUser to assume it.</p>
<h4>a. Define the Trust Policy</h4>
<p>Create a file called trust-policy.json with the following content. Replace &lt;account-id&gt; with your AWS account ID:</p>
<pre>{<br>  "Version": "2012-10-17",<br>  "Statement": [<br>    {<br>      "Effect": "Allow",<br>      "Principal": {<br>        "AWS": "arn:aws:iam::&lt;account-id&gt;:user/DevUser"<br>      },<br>      "Action": "sts:AssumeRole"<br>    }<br>  ]<br>}</pre>
<h4>b. Create the Role</h4>
<p>Create the role using the trust policy:</p>
<pre>aws iam create-role \<br>  --role-name AdminRole \<br>  --assume-role-policy-document file://trust-policy.json</pre>
<h4>c. Attach an Elevated Policy to the Role</h4>
<p>Attach a policy that provides the required elevated permissions. For example, to grant administrator access:</p>
<pre>aws iam attach-role-policy \<br>  --role-name AdminRole \<br>  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess</pre>
<h3>4. Assume the Role as the Developer</h3>
<p>When DevUser needs elevated privileges, they can use the AWS CLI to assume AdminRole and obtain temporary credentials.</p>
<pre>aws sts assume-role \<br>  --role-arn arn:aws:iam::&lt;account-id&gt;:role/AdminRole \<br>  --role-session-name DevSession</pre>
<p>The response will include temporary credentials (Access Key ID, Secret Access Key, and Session Token) valid for a limited duration. These credentials can then be used to perform administrator-level tasks.</p>
<h3>Visual Hierarchy Diagram</h3>
<p>Below is a conceptual hierarchy diagram for this example:</p>
<pre>AWS IAM<br>│<br>├── 👤 IAM User: DevUser<br>│   ├── 🔑 Access Key (for CLI/API use)<br>│   ├── 📜 Attached Policy: AmazonS3ReadOnlyAccess (default permissions)<br>│   ├── 🔄 Can Assume Role: AdminRole (for elevated access)<br>│<br>├── 🎭 IAM Role: AdminRole<br>│   ├── 🔑 Provides Temporary Credentials (when assumed)<br>│   ├── 📜 Attached Policy: AdministratorAccess<br>│   ├── 🔄 Trust Policy: Allows DevUser to assume this role<br>│<br>└── 🔐 Best Practices<br>    ├── Use Least Privilege for everyday tasks<br>    ├── Assume Roles only when elevated access is needed<br>    ├── Rotate credentials and monitor usage</pre>
<h3>Summary</h3>
<ul>
<li>
<strong>IAM User (</strong><strong>DevUser):</strong><br> Has limited permissions by default but can assume an elevated role when needed.</li>
<li>
<strong>IAM Role (</strong><strong>AdminRole):</strong><br> Grants administrator-level permissions when assumed. Its trust policy is configured to allow DevUser to assume it.</li>
<li>
<strong>Process:</strong><br> DevUser uses the AWS CLI or SDK to call sts:AssumeRole and temporarily elevate their privileges.</li>
</ul>
<p>This design ensures that elevated permissions are used only when necessary, following the principle of least privilege and enhancing overall security.</p>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=acb385675191" width="1" height="1" alt="">


How an IAM user, a role, and policies work together


<p>Below is a step-by-step guide on how to set up an IAM user for AWS CLI access, assign it the appropriate permissions (and, if needed, enable role assumption for temporary elevated privileges), and do so following production best practices.</p>
<h3>1. Define the Permission Requirements</h3>
<p>Before you begin, <strong>identify the minimum set of permissions</strong> the user needs. Following the principle of least privilege is key in a production environment. For example, if the user only needs read access to a specific S3 bucket, your policy should allow only that.</p>
<h3>2. Create a Custom IAM Policy (If Needed)</h3>
<p>If no AWS managed policy fits your requirements, create a custom policy. For example, to allow read-only access to a specific S3 bucket:</p>
<pre>{<br>  "Version": "2012-10-17",<br>  "Statement": [<br>    {<br>      "Sid": "AllowS3ReadOnly",<br>      "Effect": "Allow",<br>      "Action": [<br>        "s3:ListBucket",<br>        "s3:GetObject"<br>      ],<br>      "Resource": [<br>        "arn:aws:s3:::example-bucket",<br>        "arn:aws:s3:::example-bucket/*"<br>      ]<br>    }<br>  ]<br>}</pre>
<p>Save this JSON as custom_s3_read_policy.json.</p>
<p>You can create this policy via the CLI:</p>
<pre>aws iam create-policy \<br>  --policy-name CustomS3ReadOnlyPolicy \<br>  --policy-document file://custom_s3_read_policy.json</pre>
<h3>3. Create an IAM Group and Attach Policies</h3>
<p>Managing permissions via groups makes administration easier when you have multiple users with similar requirements.</p>
<h3>Create a Group</h3>
<pre>aws iam create-group --group-name MyCLIUsers</pre>
<h3>Attach Policies to the Group</h3>
<p>If you’re using an AWS managed policy (or even your custom one), attach it to the group. For example, to attach an AWS managed S3 read-only policy:</p>
<pre>aws iam attach-group-policy \<br>  --group-name MyCLIUsers \<br>  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess</pre>
<p>Or, to attach your custom policy (replace &lt;account-id&gt; with your AWS account ID):</p>
<pre>aws iam attach-group-policy \<br>  --group-name MyCLIUsers \<br>  --policy-arn arn:aws:iam::&lt;account-id&gt;:policy/CustomS3ReadOnlyPolicy</pre>
<h3>4. Create an IAM User with Programmatic (CLI) Access</h3>
<p>When creating the IAM user, ensure you enable <strong>programmatic access</strong> so the user can work with the AWS CLI (or SDKs).</p>
<h3>Create the User</h3>
<pre>aws iam create-user --user-name MyCLIUser</pre>
<h3>Create Access Keys for the User</h3>
<pre>aws iam create-access-key --user-name MyCLIUser</pre>
<blockquote>
<strong><em>Important:</em></strong><em> Securely store the access key ID and secret access key. They will be shown only once.</em>
</blockquote>
<h3>5. Add the User to the Group</h3>
<p>Add your new user to the group to inherit its permissions:</p>
<pre>aws iam add-user-to-group \<br>  --user-name MyCLIUser \<br>  --group-name MyCLIUsers</pre>
<h3>6. Configure the AWS CLI on the User’s Machine</h3>
<p>On the user’s workstation (or wherever the CLI is being used), run:</p>
<pre>aws configure</pre>
<p>Then provide the <strong>Access Key ID</strong>, <strong>Secret Access Key</strong>, the desired <strong>region</strong>, and <strong>output format</strong> when prompted.</p>
<h3>7. (Optional) Set Up IAM Roles for Temporary Elevated Privileges</h3>
<p>For scenarios where a user needs temporary elevated privileges (for example, administrative tasks), it’s best to require the user to <strong>assume a role</strong>. This helps to minimize risk by providing elevated permissions only when needed.</p>
<h3>a. Create a Role with a Trust Policy</h3>
<p>Create a trust policy (e.g., role-trust-policy.json) that allows your user to assume the role:</p>
<pre>{<br>  "Version": "2012-10-17",<br>  "Statement": [<br>    {<br>      "Effect": "Allow",<br>      "Principal": {<br>        "AWS": "arn:aws:iam::&lt;account-id&gt;:user/MyCLIUser"<br>      },<br>      "Action": "sts:AssumeRole"<br>    }<br>  ]<br>}</pre>
<p>Create the role using the trust policy:</p>
<pre>aws iam create-role \<br>  --role-name ElevatedAccessRole \<br>  --assume-role-policy-document file://role-trust-policy.json</pre>
<h3>b. Attach Required Policies to the Role</h3>
<p>For instance, if this role should grant administrative privileges:</p>
<pre>aws iam attach-role-policy \<br>  --role-name ElevatedAccessRole \<br>  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess</pre>
<h3>c. Assume the Role via AWS CLI</h3>
<p>When needed, the user can assume the role:</p>
<pre>aws sts assume-role \<br>  --role-arn arn:aws:iam::&lt;account-id&gt;:role/ElevatedAccessRole \<br>  --role-session-name MySession</pre>
<p>This command returns temporary security credentials (Access Key, Secret Key, Session Token) that can be used for the session.</p>
<h3>8. Production Best Practices</h3>
<ul>
<li>
<strong>Least Privilege:</strong> Only grant the permissions necessary for the user’s tasks.</li>
<li>
<strong>Multi-Factor Authentication (MFA):</strong> Enforce MFA for IAM users to add an extra layer of security.</li>
<li>
<strong>Access Key Rotation:</strong> Regularly rotate access keys and disable/delete unused ones.</li>
<li>
<strong>Logging &amp; Monitoring:</strong> Enable AWS CloudTrail to monitor IAM and API activities.</li>
<li>
<strong>Permissions Boundaries:</strong> If you need to limit what even privileged users can do, use permissions boundaries.</li>
<li>
<strong>AWS Single Sign-On (SSO):</strong> For larger organizations, consider integrating with AWS SSO or an identity provider to simplify access management.</li>
</ul>
<p>By following these steps, you’ll set up an IAM user for CLI access with a clear separation of duties — using groups and policies for day-to-day tasks and roles for temporary elevated access when needed. This approach not only adheres to AWS security best practices but also ensures your production environment remains secure and manageable.</p>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=b52c5be2c370" width="1" height="1" alt="">


How to set up an IAM user for AWS CLI access


<p>Creating a portfolio website is a great way to showcase your skills, projects, and experiences to potential employers, clients, or collaborators. Below is a step-by-step guide on how to make a portfolio website:</p>
<figure><img alt="thubmnail" src="https://cdn-images-1.medium.com/max/1024/1*xD8latIpKFO01gOBHrL2aw.jpeg"></figure><p>### Step 1: Define Your Goals and Audience<br>Before you start building your portfolio website, it’s essential to define your goals and identify your target audience. Determine what you want to achieve with your portfolio (e.g., landing a job, attracting freelance clients) and who you want to reach (e.g., recruiters, potential clients).</p>
<p>Step 2: Choose a Website Building Platform<br>There are several website building platforms available, each with its own set of features and customization options. Some popular options include:</p>
<p>- **WordPress**: Offers flexibility and customization options through themes and plugins.<br>- **Wix**: Provides an easy-to-use drag-and-drop interface for building websites.<br>- **Squarespace**: Known for its elegant templates and all-in-one platform for website building.<br>- **Webflow**: Allows for more advanced design and customization options with a visual development tool.<br>- **GitHub Pages**: Ideal for developers who want to showcase their coding projects using GitHub repositories.</p>
<p>Choose a platform that aligns with your technical skills, design preferences, and budget.</p>
<p>### Step 3: Select a Domain Name and Hosting<br>Choose a domain name that reflects your personal brand or professional identity. Consider using your name or a variation thereof if it’s available. Once you’ve selected a domain name, you’ll need to choose a hosting provider to store your website files and make your site accessible on the internet.</p>
<p>### Step 4: Design Your Website<br>When designing your portfolio website, keep the following tips in mind:</p>
<p>- Keep it simple and intuitive: Ensure that visitors can easily navigate your website and find the information they’re looking for.<br>- Showcase your work: Feature your projects prominently on your homepage or a dedicated portfolio section.<br>- Highlight your skills and experience: Include sections that showcase your skills, experience, education, and any relevant certifications or awards.<br>- Make it visually appealing: Use high-quality images, typography, and colors that reflect your personal style and professionalism.</p>
<p>### Step 5: Create Compelling Content<br>Write engaging and informative content for your website, including:</p>
<p>- An about me section: Introduce yourself and provide insight into your background, interests, and career objectives.<br>- Project descriptions: Provide detailed descriptions of your projects, including the technologies used, your role, and any notable achievements.<br>- Contact information: Make it easy for visitors to get in touch with you by including your email address or a contact form.</p>
<p>Step 6: Optimize for SEO<br>Optimize your website for search engines to increase its visibility and attract more visitors. Use relevant keywords in your content, meta tags, and image alt text. Ensure that your website loads quickly and is mobile-friendly.</p>
<p>### Step 7: Test and Launch Your Website<br>Before launching your portfolio website, test it thoroughly to ensure that it works properly on different devices and web browsers. Check for any broken links, typos, or formatting issues. Once you’re satisfied with the final result, launch your website and start promoting it to your network and online communities.</p>
<p>### Step 8: Update and Maintain Your Website<br>Regularly update your portfolio website with new projects, experiences, or achievements to keep it fresh and relevant. Monitor your website’s performance using analytics tools and make adjustments as needed to improve its effectiveness in achieving your goals.</p>
<p>By following these steps, you can create a professional and impactful portfolio website that effectively showcases your skills and experiences to potential employers, clients, or collaborators.</p>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=4d9e0fd0bfa4" width="1" height="1" alt="">


Informative

Recent Articles