DEV Community: Endah Bongo-Awah

A Cost-Effective Guide to prepare and pass the KCNA

Endah Bongo-Awah — Tue, 31 Dec 2024 00:45:24 +0000

If you're reading this, you're likely interested in Kubernetes or just curious about my journey—either way, thanks for stopping by!

I recently embarked on my certification journey with Kubernetes and decided to make it as cost-efficient as possible. Starting with the Kubernetes Cloud Native Associate (KCNA) certification, I discovered that with the right resources and strategies, you don’t need to break the bank to succeed. Here’s how I did it.

Preparation Timeline and Resources

The average preparation time for the KCNA certification is 3–6 months, depending on your prior experience with Kubernetes and cloud technologies.

Here’s the curriculum path I followed, which is well-structured and affordable:

Introduction to Linux (LFS101) - Free
Linux basics are crucial for working with Kubernetes, and this course covers the fundamentals.

Introduction to Cloud Infrastructure Technologies (LFS151) - Free
This course gives an overview of cloud technologies, which sets the stage for understanding Kubernetes.

Introduction to Kubernetes (LFS158) - Free
A comprehensive introduction to Kubernetes, perfect for beginners.

Kubernetes and Cloud Native Essentials (LFS250) - $99
This paid course dives deeper into Kubernetes concepts and cloud-native practices. It’s a great investment for serious learners.

These resources were sufficient to equip me for the KCNA certification.

Practice Makes Perfect

Studying is one thing, but practicing under exam conditions is equally important. Here are the practice resources I used, all of which are free or offer free samples:

ExamPro by Andrew Brown
Huge thanks to Andrew Brown for his free content and the complete practice exam. This resource alone boosted my confidence significantly.
Tutorial Dojo
Provides 20 free sample exam questions with detailed explanations.
ExamTopics
Offers 30 free KCNA practice questions. Beyond 30, there’s a paid option, but the free content is a great start.
ITExams
Similar to ExamTopics, with different questions.
VMExams
Features 10 sample questions per session. While many repeat, they’re still helpful for reinforcing key concepts.

Registering for the KCNA Exam - $250

When you feel ready to take the KCNA exam, you can register here: KCNA Exam Registration.

Pro Tip: Keep an eye out for sales on the Linux Foundation website! They often offer discounts of up to 60%, which can make certification significantly more affordable.

Key Takeaways

Follow a structured path: The Linux Foundation’s resources are a reliable and affordable starting point.
Practice consistently: Use free materials to test your knowledge and get a feel for the exam format.
Stay cost-conscious: By leveraging free resources and only spending on essentials, you can prepare for KCNA without overspending.

I hope my experience inspires and helps you on your own certification journey. Kubernetes is a fascinating and valuable skill, and earning the KCNA certification is a fantastic first step into the world of cloud-native technologies.

What comes next? Consider showing off your Kubernetes & cloud native security skills by earning your Kubernetes and Cloud Native Security Associate (KCSA) or go next level with the Certified Kubernetes Administrator (CKA) certification, Certified Kubernetes Security (CKS) and Certified Kubernetes Application Developer (CKAD)

Feel free to connect with me or share your thoughts in the comments. Best of luck on your Kubernetes journey!

A Journey of GenAI with AWS Bedrock based sample Images

Endah Bongo-Awah — Mon, 30 Dec 2024 15:41:38 +0000

In the not-so-distant past, machines were relegated to mere calculation and automation. Today machines can create, innovate, and even rival human imagination! Is GenAI slowly dissolving the lines between human creativity and artificial intelligence? Let's journey through the early days of Generative AI...

Before that, here is a little back story of "how I met Bangaly"

I have known and admired Bangaly's professional accomplishments for more than a year now. He has over 1000 Badges, a CNCF Kubestronaut, a AWS Golden Jacket , 17xAWS, 14xGCP, 17xMicrosoft, 6xComptia, 4xHashicorp, 4xGithub, 3xOCI, and many more. I couldn't comprehend how he achieved that, so I did the only logical thing, ask him!

The answer wasn't anything we all haven't heard before. There was the irritating consistency, the annoying hardwork, never missing curiosity and a the magical kindness

View the crazy things he has accomplished here ☞Bangaly's LinkedIn

We are kind of an odd duo, with a shared passion to encourage, empower and share knowledge with our community. We shall be creating series of content surrounding the realm of AI, ML and all the fun stuff around Cloud Computing.

Let's start from the beginning.....

Artificial Intelligence has been lingering around since 1941!

In 1950, Alan Turing published a paper titled "Computing Machinery and Intelligence" in which he proposed the imitation game.
The game involves: Three participants: a human interrogator, a human respondent, and a machine.

The interrogator's goal is to determine which of the other two participants is the human and which is the machine.
Communication is limited to text-only exchanges.

The machine aims to fool the interrogator into thinking it is human. Turing argued that if the machine could consistently fool human interrogators, it should be considered to exhibit intelligent behavior. The term Artificial Intelligence was officially coined on august 31, 1955. Here is the link to the article

What then is machine learning?

Machine Learning is a subset of Artificial intelligence. The idea behind machine learning is to feed large amounts of data into algorithms, which can then identify patterns and relationships in the data, and use that knowledge to make predictions or decisions without relying on hard-coded rules. Arthur Samuel, an IBM researcher, is credited with coining the term "Machine Learning" in 1959.

and Deep Learning is...

Deep Learning is a specific type of machine learning that gained widespread attention in the 21st century. It is inspired by the structure and function of the human brain and involves the use of artificial neural networks (ANNs), which are computational models that mimic the interconnected neurons in the brain.

Deep learning algorithms can automatically learn complex patterns and representations from raw data, making them highly effective for tasks like image recognition, natural language processing, and speech recognition. While the fundamental concepts of neural networks date back to the 1940s and 1950s, with pioneers like Warren McCulloch and Walter Pitts, deep learning only became practically viable in the late 2000s due to advances in computing power, availability of large datasets, and algorithmic improvements.

In summary,

AI is the overarching field, machine learning is a subset of AI that focuses on learning from data, and deep learning is a specific type of machine learning that uses artificial neural networks.

These fields have evolved over time, with each advancement building upon the foundations laid by previous researchers and breakthroughs.

A Question we should ask ourselves is, if AI has been around for this long, why is it gaining popularity decades after?

Early AI researchers faced several significant challenges as they worked to develop artificial intelligence in the 1950s and 1960s. These included:

Limited Computing Power: Early computers lacked the processing power and memory needed for complex AI algorithms and large data processing.

Unrealistic Expectations: Early AI pioneers were overly optimistic about achieving human-level AI quickly, leading to disappointment when progress was slower.

Lack of Understanding of Intelligence: Researchers underestimated the complexity of human cognition, thinking it could be easily replicated in machines.

Narrow Focus: Early AI research focused on specific tasks like chess, which didn’t translate well to general intelligence or common sense reasoning.

Funding Challenges: AI research experienced cycles of enthusiasm and funding, followed by “AI winters” where interest and financial support dried up.

Software Limitations: The bottleneck in AI development was often software, as creating programs that mimicked human reasoning was very difficult.

Lack of Data: Early researchers didn’t have access to the large datasets needed for effective AI training, limiting their models’ effectiveness.

How have we overcomed these challenges?

Access to Artificial Intelligence has been democratized and its capabilities are continuously advancing. It has also led to generative AI, a game-changing technology.

Generative AI refers to artificial intelligence models that can generate new data, such as texts, images, audios, or videos, based on the patterns and relationships learned from training data, and it is still evolving.

One of the key players in democratizing access to generative AI is AWS Bedrock, a comprehensive platform developed by Amazon Web Services (AWS) that provides developers and researchers with the tools, infrastructure, and resources needed to build and deploy generative AI models.

AWS Bedrock leverages the power of cloud computing, offering scalable and cost-effective solutions that enable users to train and run large-scale generative AI models without the need for expensive on-premises hardware. By removing barriers to entry, AWS Bedrock has empowered individuals and organizations of all sizes to explore and leverage the capabilities of generative AI.

AWS Bedrock use-case.

Let's illustrate one of the capability of AWS Bedrock using AWS management console.

How to create an Image on AWS Bedrock
This can be done in 3 simple steps

Step 1

You require an AWS Account, which is free. Be aware that most of the models are third party tools and will be charged separately, even though you have AWS Credits. We learned the hard way 🙃💸
Log into the account and move to the AWS Bedrock UI.

AWS Bedrock UI and its functionalities

Step 2

Request for access from the desired model

Step 3

Image generated from desired image

AWS Samples contains pre-built examples to help customers get started with the Amazon Bedrock service.

We shall be exploring more of them in our next content.

Stay tuned....

Bangaly and Endah

Organizing a virtual AWS re:Invent@home: A Behind-the-Scenes Look

Endah Bongo-Awah — Thu, 19 Dec 2024 23:31:33 +0000

Planning and organizing a virtual global event like reInvent@Home comes with feelings such as excitement, anxiety, stress, relief, and the best of all satisfaction and reward.
Last year, in 2023, AWS introduced the concept to bring a percentage of the energy and excitement of re:Invent to those who couldn’t attend in person.
This year, a small but passionate team, comprising of Annem Shah, Oluwasegun Adedigba, Andreas Rütten and myself organized a first ever community led re:Invent@home.

Our intention was to create a welcoming and engaging virtual space for attendees around the world.
Here’s how we brought it all to life, the lessons we learned, and tips for anyone looking to organize a similar event.

The Start: Turning an Idea into Action 💡📙 📝

The idea to organize reInvent@Home started with a shared enthusiasm for connecting with the global AWS community. Some of us had attended last year’s re:Invent@home, others had been to Las Vegas for the live re:Invent experience, and a few were simply inspired to try something new.

Once we assembled a like-minded group, we rolled up our sleeves and got to work. Our first step? Establishing a central meeting point where everyone involved could collaborate seamlessly.

Planning Across Borders: Navigating Time Zones and Busy Schedules ⏲ ⏳

Planning an event of this magnitude meant overcoming logistical challenges. With team members spread across different time zones, we were fortunate that the differences were minimal, just two hours apart.

To make the most of our time, we set a regular meeting schedule:

Three months before the event: Weekly meetings to brainstorm and outline the event structure.
One month out: Increased to three meetings per week to refine details and tackle action items.

Every meeting started with updates on designated tasks, ensuring accountability and progress. Of course, there were days when someone couldn’t attend, but our mantra was simple: the show must go on!

Laying the Foundation: Tools and Strategies ✍🏻💻🗂

We relied on a variety of tools and strategies to streamline the planning process:

Collaboration Tools: A shared spreadsheet became our central hub for brainstorming, tracking ideas, and assigning tasks.
Participant Outreach: To gauge interest, we created a Google Form for attendees and potential speakers, setting clear timelines for submissions.
Communication Channels: We combined all community members interested in the planning into a Slack channel, which became our event’s heartbeat.

In Slack, we shared event updates, fostered daily conversations, and created excitement leading up to the event.

Making It Interactive: The Event Blueprint 🎡👨‍👩‍👧‍👦

To keep attendees engaged, we designed a mix of live sessions, watch-alongs, and interactive discussions. Key elements included:

Keynotes: Keynotes are huge!! We scheduled watch-alongs for the major keynotes, starting meetings five minutes early for networking and running discussions afterward.
Daily Sessions: Inorder to enforce collaboration, knowledge sharing and networking within the community, we offered a range of 45–60-minute talks/presentations based on AWS services.
Daily Recaps and Previews: Each day began with an agenda and ended with highlights, ensuring everyone stayed informed and involved.
Swag and Fun: Thanks to the incredible support from AWS, we distributed swag to all speakers and selected daily winners to add an extra layer of excitement.

Lessons Learned: Tips for Future Organizers 🧠🙌🏻
Reflecting on the experience, here are some key takeaways for organizing a virtual event:

Engage Early and Often: Start building momentum well in advance with consistent communication.
Leverage Technology: Use platforms like Zoom or WebEx for live sessions and Slack for ongoing discussions.
Stay Flexible: Have backup plans for no-shows or technical glitches.
Prioritize Fun: While structure is important, creating an enjoyable and memorable experience should always be the goal.

Swag: A Token of Appreciation ✨🎁
No event is complete without swag! As a small token of appreciation, we received some amazing AWS swag for our efforts, which added to the joy of organizing. Sharing a photo of my swag haul feels like the perfect way to celebrate the journey and the connections we made along the way:

I received:

A builders big bag of adventure (In black). Optimal for AWS events and meetups. It can contain a 16 inch laptop and other items.
A white building T-Shirt
A think big notebook and
AWS BuildersCards Resilience Expansion

I love my package.Thank you AWS Community. 🥰🥰

Looking Ahead: What’s Next for reInvent@Home?
Organizing reInvent@Home was a rewarding experience that demonstrated the power of collaboration and shared passion. For those seeking inspiration to organize similar events, I hope our journey serves as a helpful guide.

The question now is: how will you create your next big virtual event? Let’s continue to innovate, connect, and grow as a global community.
Looking forward to the re:invent@home2025 What new ideas do you suggest we engage in next year?

Life in KubeCity- How it all began

Endah Bongo-Awah — Sat, 20 Jul 2024 09:15:12 +0000

I don’t know about you, but whenever someone starts a story with the words..Imagine that….They got my undivided attention. I am a sucker for storytelling teaching methodology.
I struggled to understand the fundamentals of kubernetes and once I did, I thought that I would have understood it faster if it were told to me as a story.

So if you are new to the concept of kubernetes (which by the way is 10 years old, so no pressure!), this story might just polish up some concepts you needed help understanding (as i did) or ease your understanding of the fundamentals of kubernetes.

At the end of this story;

You should have a better understanding overview of kubernetes object in a fun way.
Understand the functions of the common objects of kubernetes.
Understand the essential objects that come together to create a stable secure Kubernetes cluster.

Let us start with a classical introduction.....
Me: Arabian nights…. You: Entertainments
Me: Boys and girls are you ready to hear my story…. You: Yes we are, what is the story about.....

10 years ago, in the vibrant and bustling city of Kubernetes, where microservices and containers thrived, there lived many remarkable residents, each with a unique role to play. Admired all across the universe, tasked with control and orchestration, ensuring everything moved like a well-choreographed cosmic ballet, kubernetes was the talk of the town.
Before the city Kubernetes became too famous and organized, Kubernetes lived only with its containers and wished for companionship and help in orchestrating its vast responsibility of managing its containers.

From the wish sprang forth Pods, the smallest, most elemental creators in the universe. Kubernetes found companionship in these Pods, who were always ready to host containers, acting as individual performers in the orchestrated ballet, dancing gracefully to Kubernetes' tune.

Next, came Services. In the grand cosmos, they acted like the messengers between Pods and the outside universe—charming, consistent, and buoyantly helpful. Services held hands with Pods, helping them communicate, and won Kubernetes' affection

It was realized that, information from the activities needed storage, so Volumes was hired. These were the loyal librarians, remembering and storing every important detail. Their persistence and memory were like a warm blanket on a cold night for Kubernetes, providing comfort and a level of security.

Kubernetes was in need of some order in its kingdom, the pods needed to be managed and who else than our powerful and flexible manager deployments. Kubernetes then met Deployments and ReplicaSets who were twins. Deployments were like the caring managers, ensuring the desired state of applications, whereas ReplicaSets were like the diligent generals, securing the required number of Pods. Together, they added balance and stability, making Kubernetes’ heart flutter. However deployments always left things in a temporal state, causing chaos and instability

One day, Deployment wandered into a Kubernetes meetup and met StatefulSet. Deployment was immediately captivated by StatefulSet's grace and stability. They began to spend more time together, and Deployment quickly realized how much they complemented each other. Here are some of the qualities that made StatefulSet irresistible:

Its reliable Identity. This was like having a partner who never changed their phone number or email address – always reachable and reliable.
Persistent Storage: it was like being with someone who never lost their keys or forgot important dates.
Graceful Updates: Pods were updated one at a time ensuring stability and minimal disruption
Ordered Deployment: Methodical approach to deploying and scaling pods

As the Deployment and StatefulSet’s relationship blossomed, they were often joined by their steadfast friend, DaemonSet. DaemonSet ensured that essential services, like logging agents and monitoring tools, ran on every node in the cluster. DaemonSet’s thoroughness and dedication was admired by all.

Deployment hired Job, a diligent servant, responsible for running specific tasks to completion. They ensured that batch processing and other time-bound tasks were executed successfully.

Secrets was a confidant, keeping sensitive information, such as passwords and API keys, secure. They ensured that this data was stored securely and accessed only by those who needed it.

ConfigMaps became Deployment’s organizational friends, providing configuration data to Pods. They ensured that applications could be configured dynamically without the need to rebuild images.

With the city of Kubernetes growing, order needed to be maintained. Namespaces were hired to create multitudes of realities within the city. They isolated applications in their own virtual realms.

With this attained achievement, kubernetes organized a housewarming party. Invited guests came from far and wide. Kubernetes needed to prepare for them. So security officers called Networkpolicy, which ensure that only selected, authorized guests talked with the pods, fostering a secure environment for all in the city.

A gatekeeper called Ingress was also hired, a devoted traffic manager, effectively controlling in and outbound traffic. Ingress mapped guests to their respective services, ensuring a smooth and efficient flow of traffic.

As the party grew and the communication between guest increased, services needed assistance, so Endpoints were hired! They acted like dynamic telephone operators. They facilitated communication by routing calls from services to the relevant pods.

To ensure the no one at the party was overwhelmed, needs are met and no wastage of resources, the twin brothers Limits and requests were hired. While requests kept a check on how much each quest could consume to remain entertained, limits made sure the overall consumption stayed within the agreed upon amount.

There were invited guests referred to as service accounts with designated tasks. Roles and rolebinding were hired to manage access control and permissions into various party locations in an organized and secure manner.
Clusterrole and clusterrolebinding assumed the same governing principle and expanded it citywide

In the ever-evolving city of Kubernetes, the residents were content with the structures and systems in place. But as time passed, the citizens dreamed of new and unique buildings that could serve purposes beyond what was currently possible.

From this desire, the Custom Resource Definitions (CRDs) emerged, the visionary architects of Kubernetes City. They brought with them the ability to design new types of buildings—structures that were not originally part of the city’s blueprints but were now essential for its growth and diversity.

These CRDs allowed the inhabitants to define their own types of Pods, Services, and Controllers—each with its own special features and behaviors. They were like custom-made homes and offices, tailored to the specific needs of their owners, yet seamlessly integrated into the city’s landscape.

As the sun sets on Kubernetes City, all the objects gather to enjoy the power of collaboration and innovation.

But this is not just the end of our tale; it’s the beginning of your journey in Kubernetes City. As you wander through its streets, you’ll discover more secrets, encounter new challenges, and perhaps, contribute to its legacy.

Now, dear reader, it’s your turn to share your thoughts. Did you find a favorite character in our story? Is there a concept that you’d like to explore further? Your insights and questions are the bricks and mortar that will help build the next chapter of Kubernetes City.

Please, step into the town square and voice your ideas:

What did you enjoy the most about our Kubernetes narrative?

Which Kubernetes object would you like to hear more about?

Do you have suggestions for new characters or features to add to the story?

Your feedback is invaluable, and together, we can continue to demystify the world of Kubernetes, making it accessible and enjoyable for all.

Thank you for joining me on this adventure. I look forward to hearing your tales and experiences in Kubernetes City. Until next time, keep exploring and innovating!

How EKS Pod Identity provides a more secure and optimized AWS services -Applications connectivity.

Endah Bongo-Awah — Wed, 31 Jan 2024 22:43:50 +0000

Every AWS Re-Invent new releases are awaited with high expectation. One of my highlights of the reinvent 2023 was the simplified application access to AWS service with EKS pod Identity. My Kubernetes journey started sometime in 2021 and I have grown to love it, not only because it is greatly leveraged at my job, but also because of its extremely improving power as a micro-service. If all of this is new to you, check-out the link below on getting starting with Kubernetes on AWS.¹

What is Amazon EKS Pod Identity?

Amazon EKS Pod Identity is a feature within Amazon Elastic Kubernetes Service (EKS) that simplifies the process of managing AWS Identity and Access Management (IAM) permissions for Kubernetes applications running on Amazon EKS clusters. It allows you to assign specific IAM roles to individual Kubernetes pods, ensuring granular and secure access to AWS resources and APIs.

How was this managed prior to EKS Pod Identity?

Before the introduction of EKS Pod Identity, the primary way to manage IAM permissions for Kubernetes pods was through solutions such as:

Kube2iam

An open-source solution that assigns IAM roles to Kubernetes pods running in an Amazon EKS cluster. It creates a secure and controlled way of managing pod-level IAM access. The mechanism behind kube2iam is to intercept AWS metadata API requests from pods, check their attributes, and provide the appropriate IAM credentials based on a pod's annotation or Kubernetes namespace.
While kube2iam has been helpful in securing pod-level access to AWS resources, it has certain challenges:

Additional component to manage: As kube2iam operates as a separate component, it increases overall management overhead.
Complex configuration: Setting up and configuring kube2iam can be complex, requiring multiple steps and in-depth knowledge about AWS networking and IAM.
Limited support for new features and improvements: kube2iam is a community-supported project, potentially making it slower to introduce new features or bug fixes compared to AWS managed services.

kiam

Another open-source solution that provides a secure way to manage pod-level AWS IAM roles in Kubernetes clusters. It intercepts AWS metadata API calls from the pods and responds with the appropriate IAM credentials based on annotations. Kiam has a more robust security model than kube2iam, achieved by separating the roles of a metadata agent and a server, with strict communication policies enforced using TLS and gRPC.

AWS Security Token Service (STS)

Using the AWS STS, you can create short-lived credentials to manage access to AWS resources from within Kubernetes. This method works by assuming an IAM role in a pod and using the aws sts assume-role command to obtain temporary credentials. While STS is a useful mechanism for providing temporary access to AWS resources, it can be cumbersome to maintain and less flexible when compared to kube2iam or kiam.

AWS IAM Roles for Service Accounts (IRSA)

Amazon introduced AWS IAM Roles for Service Accounts (IRSA) as an official AWS solution that streamlines pod-level IAM access within EKS clusters. IRSA allows you to associate an IAM role directly with a Kubernetes service account, so that applications running within a pod can use the role without sharing any credentials in the process. This automation simplifies and enhances security in managing pod-level AWS access.
While there are several alternatives available for managing IAM permissions in Kubernetes, EKS Pod Identity seeks to provide a robust and easy-to-use native solution for Amazon EKS users.

What makes Amazon EKS Pod Identity a more powerful tool?

Amazon EKS Pod Identity offers several advantages for managing IAM permissions in EKS clusters:

Simplified permissions: With EKS Pod Identity, you can assign specific IAM roles at the pod level. This granular control allows each pod to have the required permissions to access only the necessary AWS resources, simplifying the permissions management process and ensuring a more organized cluster.
Enhanced security: By following the principle of least privilege, EKS Pod Identity enables enhanced security measures for the applications running in the EKS cluster. It limits each pod's access to only the permitted resources, reducing the potential surface area for exploitation.
Native integration: EKS Pod Identity is designed to work natively with Amazon EKS and AWS SDKs. This seamless integration ensures a more efficient developer experience while managing IAM access for their applications in the cluster.
Ease of management: Compared to third-party solutions like kube2iam or kiam, EKS Pod Identity provides a more streamlined, native approach to IAM management. It eliminates the need for additional components and simplifies the overall management process, making it easier for administrators to maintain a secure and organized EKS environment.
Automatic credential provisioning: EKS Pod Identity automates the process of providing temporary security credentials to pods when they make AWS API requests. This automation not only keeps the environment secure but also minimizes the complexity involved in credential management and IAM role assumption.

Hands-On Demo

Let's experience the power of EKS Pod Identity.

Requirements:
An AWS Service (s3 bucket): We shall create an s3 bucket, upload an image and later on access it.
An Application: As we know applications are housed in Containers and containers resides in pods. These pods are managed by Kubernetes, so we need an EKS Cluster.
IAM Permission: For Identity and Access management.

An S3 bucket named myeksbucket-01 was created and an image uploaded into it.

I created an IAM Role called eksClusterRole and attached a permission policy so as to get access to the created s3 bucket.

Next to the permission, we need a Trust Relationship with a principal labelled pod.eks.amazonaws.com.

Next we need the pod identity agent, which will reside in the EKS Cluster. We need to create a cluster. The default setting will suffice. For the add-ons stage, It is important to chose amazon EKS Pod Identity agent as an extra add-on

We need create a pod identity association. The Kubernetes namespace and service account can be created on the fly, if you don't already have in your cluster. Just enter the desired names in the field.

The Cluster creating process might take up to 15 minutes.

After the successful creation the cluster, we need to access it through the AWS-CLI on the same browser with the following command:

Next we access the service as shown below:

The following commands can be used to map the IAM role to the Kubernetes pod:

$ aws eks create-pod-identity-association \
--cluster-name \
--namespace \
--service-account \
--role-arn

The following command can be used to install the EKS Pod Identity Agent into the cluster:

aws eks create-addon \
--cluster-name \
--addon-name eks-pod-identity-agent \
--addon-version

These are further steps on achieving the required results. ²

I hope these blog was helpful. I look forward to feedback and collaborations.

10 Best Practices for securing a kubernetes cluster with AWS

Endah Bongo-Awah — Fri, 12 Jan 2024 22:11:05 +0000

In this article, we will discuss Kubernetes security best practices and explore various solutions provided by Amazon Web Services (AWS).

As more organizations adopt microservices architecture, securing Kubernetes clusters becomes increasingly important. Kubernetes security comprises multiple levels - the underlying infrastructure, the Kubernetes platform itself, and the applications running within the clusters. Setting up a kubernetes cluster and configuring the deployment is already challenging enough and the security part is frequently left for after.

Important questions to ask when considering securing your kubernetes cluster:

How is a kubernetes cluster secured by default?
If i dont do anything, how secure are my resources?
What are the security vulnerability gaps?
What are the security best practices to close those gaps?

Security is a combination of multiple things at multiple levels. It is not just one or 2 things.

There are several security issues and vulnerabilities that could be encountered while building and deploying applications. To prevent these vulnerabilities, we can implement best practices.

Access Control & Privilege Escalation
Insufficient Logging & Monitoring
Security Misconfigurations & Default Configurations
Improper Secrets Management...just to name a few_

1. Image Scanning

The first step in building an application is building a secure image in the cicd pipeline. What security issues do we have here?
Here are 3 possibiliites:

Code from untrusted repositories: Code or Libraries in our application from untrusted registries/source. These may include virus or backdoors that grant access to an attacker.
Vulnerabilities in the operating system or libraries: We may also be using some packages in the operating system in our docker Image. These dependencies and tools may also have some vulnerabilities. Or the base Image we are using, may have some vulnerabilities.
Unnecessary dependencies: Choose leaner and smaller images, with less tools inside required to build the application image. An attacker can use a vulnerability in the container to break out and have access to the host or the kubernetes worker node

To mitigate such vulnerabilities, Scan container images using tools like AWS signer, which is a fully managed code-signing service to ensure the trust and integrity of your code. AWS also offers the Elastic Container Registry (ECR) image scanning solution. Regularly scanning images in the cicd pipeline before pushing it into the repository can help prevent vulnerabilities. ¹

2. Avoid Root-Users in Containers and Run as Non-Root

Create service users and run applications with non-root users. Running containers with limited privileges will help harden security.
AWS provides Amazon Inspector which uses the service-linked role named AWSServiceRoleForAmazonInspector2. This service-linked role trusts the inspector2.amazonaws.com service to assume the role. ²

3. Use RBAC for User and Permission Management

Role-Based Access Control (RBAC) allows defining user roles and their permissions in Kubernetes. Make sure to adopt the least-privilege approach when assigning permissions.
AWS offers Attribute-based access control (ABAC), which is an authorization strategy that defines permissions based on attributes. In AWS, these attributes are called tags.
These tags can be attached to users, roles or resources. ³

4. Implement Network Policies

Use Network Policies to define which pods can communicate with each other and how traffic is distributed among them. As the name implies, network policy configures communication rules at a network level, if we want to define these rules at service level or an application level, which is a more logical level for cluster communication. We can use service mesh such as Istio. Calico or Weave are popular Kubernetes network plugins for implementing network policies. ⁴

5. Encrypt Communication with mTLS

By default all communication between pods is unencrypted So if an attacker gets into a cluster, they will be able to see all the communication.. in plain text!! Make use of service meshes like Istio to enable mutual Transport Layer Security (mTLS) to encrypt communication between pods. ⁵

6. Secure Secret Data with AWS KMS Or HashiCorp Vault

Another thing which is not secure by default is the secret. They are base 64 encoded, so anyone who wants to view the secrets, can simply decode it with base64 –decode and see them in plain text. Use EncryptionConfiguration to enable encryption of Kubernetes secrets or adopt third-party solutions like AWS Key Management Service (KMS) and HashiCorp Vault to manage secret data. ⁶

7. Secure the etcd Data Store

Secrets and all other k8s configuration data are stored in etcd, which is k8s backing store for all cluster data. Etcd resides in the control plane, having access to this will mean having access to the whole cluster. It is best to secure this… but how?
Protect the etcd data store by placing it behind a firewall and implementing proper authentication and encryption. In addition to that, the data can be encrypted, such that even if the attacker gets access to it, they won't be able to read it. RBAC as well as kubernetes best practice. ⁷

8. Regularly Backup and Restore Data

Attackers are known for infiltrating systems, stealing data and asking for ransom (Huge sums of money). This is a nightmare to every organization.
Automate backups and implement an immutable storage system using tools like velero. Velero is a popular open-source tool that can back up Kubernetes cluster resources and persistent volumes to externally supported storage backend on demand or by schedule. AWS customers can leverage this solution to centrally back up and restore Kubernetes objects and applications from and to EKS. ⁸

9. Configure Security Policies

Let's say as a Kubeadmin, you know and apply the above best practices and try to protect data and cluster. Clusters are usually used by developers. How do we make sure that these developers also apply these best practices when deploying their applications? Rules, such as pods that run privilege containers or containers with root-user cannot be deployed.The rules should also define network policy for every pod. The Kubernetes Pod security policy admission controller validates Pod creation and update requests against a set of rules.
Use third-party tools such as Open Policy Agent (OPA) or Caverno to automate the validation of security configurations and avoid misconfigurations. ⁹

10. Implement Disaster Recovery

Applying all of these best security practices is no 100% guarantee that an attack won’t occur. Ensure that there is a disaster recovery plan in place and tools are in use for automating cluster recovery.
AWS implements backup and recovery approaches for on-premises, cloud-native, and hybrid architectures. These approaches offer lower costs, higher scalability, and more durability to meet recovery time objective (RTO), recovery point objective (RPO), and compliance requirements.
¹⁰
By following these best practices and leveraging AWS solutions for Kubernetes security, you can protect your Kubernetes clusters and applications from potential vulnerabilities and build a robust infrastructure.

Read about AWS Signer ↩
More on Amazon Inspect ↩
RBAC with AWS ↩
Configure your cluster for Kubernetes network policies - Amazon EKS ↩
Configure mTLS ↩
Secure sensitive Data ↩
Securing Kubernetes Secrets ↩
Restore with Velero ↩
Securing Pods ↩
Disaster Recovery ↩

My First AWS Event Experience: AWS Summit Berlin 2023

Endah Bongo-Awah — Wed, 27 Dec 2023 23:04:12 +0000

Some might be wondering why a post about the AWS Summit Berlin that happened in Mai (about 7 months ago) is being posted in December. I was going through my yearly activities and documentations, and discovered I didn't post about my first ever event as an awscommunitybuilder.
I would have led this slide, but the series of events before and during which were meant to stop me from attending the vent, didn't succeed in stopping me.

I'm excited to share my experience from earlier this year, back in May, when I attended the AWS Summit in Berlin. It was a rollercoaster of emotions leading up to the event, but I am so glad I pushed through and made it there! Here's a recount of my first-ever AWS event.

Overcoming Obstacles to Attend 🙅🏾‍♀️ 🥷🏽

Joining the AWS Community Builder program was a fantastic opportunity, and I'd promised myself to attend all AWS-related events I could. AWS Summit Berlin was the first on my list. However, the days leading up to the event were challenging. My husband was hospitalized, finances were tight, my kids' activities increased, and my 80-year-old mother-in-law, who lives with us, fell sick with a toothache and I had to accompany her on the series of hospital visits. It seemed like everything was conspiring against my attendance.

Despite these challenges, I knew I didn't want to miss the summit. The flights and trains to Berlin became increasingly expensive, so I opted for a Flixbus (an 8 hour journey) to save on costs and arrived two hours later than planned , but I was not deterred!

Hitting the Ground Running 🏃🏽‍♀️🏃🏽‍♀️

I arrived at the summit full of energy and ready to network, but my appearance didn't look the part. I quickly applied some makeup at the entrance and wasn't bothered about my surroundings. I entered the venue, and it took me a minute to let everything sink-in. The energy was encouraging, entertaining, welcoming and inspiring to say the least. I collected my batch and contemplated on the next best action.

Exploring the Summit and Networking 👩🏾‍💻 🔍

Once I met most of the community builders in person at the AWS Community Lounge, I set off to explore the event. I attempted to go visit every stand. This wasn't possible at the first try.The summit offered a wealth of insights and innovative ideas, showcasing efficient new ways to optimize cloud services.

Networking with cloud enthusiasts and colleagues was an incredible experience. Sharing my own journey in cloud computing and discussing real-life problem-solving made me feel empowered.

Swags, Stickers, and More! 😎 🤩

I finally got to "pimp" my laptop with all sorts of AWS and cloud computing stickers. The community builders were all invited for dinner and beer. Thanks to the management of AWS communitybuilders. We socialized and had some great conversations with our leaders and heroes.

The event swag was another highlight: I received an AWS hoodie, mug, bags in various colors, a T-shirt and socks from Reply, and several pens, office supplies, and souvenirs from different cloud providers.

Inspiring Keynote Speakers ♘

The keynote speakers were fantastic, featuring people I never thought I'd meet in person, such as Viktoria Seeman and Taylor Jacobsen. She shared inspiring words for women in the field, and you can find more information on my LinkedIn here

The AWS Summit Berlin was an unforgettable experience, and I encourage all cloud enthusiasts to attend an AWS event if you can. I missed my bus back home and had to spend 6 hours at the train station. I met an amazing young lady at the station who missed her train to Paris as well. She was in tears, so i consoled her with some of my swag. We cheered each other and ended up laughing over our mishaps.
Things always workout if we don't give up!
Don't be discouraged!
I'm looking forward to the next one!

AWS re:Invent 2023@home - An AWS Community Builder's Experience

Endah Bongo-Awah — Mon, 04 Dec 2023 22:54:51 +0000

As an AWS Community Builder, I had high hopes to attend AWS re:Invent 2023, which has been consistently taking place in Las Vegas on a yearly(usually in November) basis since 2012. Like many others, I counted heavily on the "AWS All Builders Welcome Grant" to cover my costs. The grant comes with prerequisites,which I met, and by no means was a gaurantee that I will get it. However, my plans changed when I didn't receive the grant. Left without a plan B, I was left wondering how things might unfold...🤔

Fortunately, AWS surprised us all by launching re:Invent at Home for the very first time! This virtual experience allowed AWS Community Builders, Community Heroes, and AWS enthusiasts from around the world to attend, watch keynote speakers live,network, hangout,co-work and share their views on favorite announcements. In this post, I share my experience attending re:Invent 2023 from the comfort of my home.

Accessible to All 💻💻

One of the biggest perks of re:Invent at Home was that it made the event much more accessible. No longer did you need to worry about travel expenses or the grant to participate. The announcements, insights, and advice from these influential speakers were invaluable and motivating. This virtual format allowed AWS fans to enjoy all the insightful content from anywhere in the world.Yes I know, being there would have been mermerizing 🤩🤩

Interactive Sessions and Networking Opportunities ⌨👨🏻‍💻

A major concern for virtual conferences is whether they provide engaging activities and networking opportunities. I am happy to report that re:Invent at Home excelled in this regard. For instance, there were daily Happy Hours that featured trivia games and opportunities for attendees to bond with one another.
There were also Show and Tell sessions where fellow builders and AWS enthusiasts presented their projects and thoughts on a variety of AWS-related topics. As a result, I learned a lot from their experiences.

Exciting exclusive reinvent Swags 😎😎

Who doesn't love swag? AWS re:Invent at Home didn't let us down on this aspect either. Special (reinvent exclusive) swag was up for grabs, and fortunately, everybody and interacted in one way or the other won something. To make things even more exciting, AWS announced a daily re:Invent at Home winner – and I was the lucky winner on Day 1!💃💃 It's moments like these that make participating in such events truly memorable.

My Experience 👩‍🏫👩‍🏫

Attending AWS re:Invent 2023 virtually was a unique and rewarding experience. I gained valuable insights into AWS services and advancements, interacted with like-minded individuals, and expanded my knowledge and potential. This was all possible without even stepping foot in Las Vegas.

AWS re:Invent at Home has shown that even when circumstances hinder us from meeting in person, the learnings and connections can still go on. As our world adapts and changes, the virtual format of re:Invent has proven that we can continue to gain invaluable insights and connections from the comfort of our homes.

Now that you know my experience, I encourage you to consider attending virtual conferences like re:Invent at Home in the future, if your "plan A" doesn’t work out or you intentionally want to express something different. This may provide you with the knowledge, community, and motivation you seek, all without the need to travel or obtain a grant.

Useful Links for Informative Content 🕵️‍♂️🕵️‍♂️

For those who missed the live event or want more in-depth information, here are some links to the keynote speakers, AWS announcements, and blogs.
Missed the keynotes? Click here 👉 https://reinvent.awsevents.com/
Interested in reinvent2023 announcements?
Click here 👉 https://aws.amazon.com/de/blogs/aws/top-announcements-of-aws-reinvent-2023/

I really enjoyed Dr. Werner Vogel's keynote on cost optimization and sustainability. Check on the 7 laws of a frugal architecture here 👉https://thefrugalarchitect.com/

How was your reinvent2023? Where did you experience it? Which was/were highlights?