# Introduction to Kind

Primarily designed for testing Kubernetes, Kind (**K**ubernetes **in**side **D**ocker) is a tool for running local Kubernetes clusters using lightweight Docker container “nodes”. 

Production-grade Kubernetes clusters require at least 2 physical/virtual servers (nodes). As Kubernetes proliferated and its tooling improved, Kind came in handier. Especially for use cases that assumed a cluster environment but were resource-constrained or did not have the high resource/availability requirements of multiple servers. For example, Kind enables local development and testing of applications that otherwise need a full-fledged production-grade cluster for deployment.

This article describes what Kind is, how it works under the hood, some common real-world use cases where Kind shines, and finally, how Adaptive leverages functionality provided by Kind to set up bastion hosts and create lightweight environments for teams which do not have an existing Kubernetes environment.

# What is Kind?

Kind is a suite of tools designed to rapidly create Kubernetes clusters in a local development environment. It is an ideal option for developers who want to test their Kubernetes applications without having to go through the hassle of provisioning physical or cloud-provided clusters. It replicates the Kubernetes environment, so existing tools that work with Kubernetes work seamlessly with Kind, but without the typical node requirements. 

Each “node” in a Kind cluster is a Docker container, which is built on top of a Docker image that contains the necessary files and binaries required to set up nested containers, and a functional Kubernetes runtime.

The ideal use case for creating Kind clusters is for local development, testing, and prototyping, however, it is not suitable for production-level workloads.


## Components of Kind

Kind is divided into:

1. The command line tool `kind` for end users
2. A node image for the container that acts like a cluster node. To be able to run Kubernetes inside the container, the image includes k8s binaries on top of a minimal base image required to run k8s. The minimal base image is built using a minimal Ubuntu image and adds packages for -
    - Running services (systemd)
    - Kubernetes components
    - Networked-backed storage with Kubernetes
    - Container runtime
    - Use by Kind
    - for semi-core Kubernetes functionality
3. Go packages that implement most of the functionality

# How Kind Works?

Kind simplifies the creation of local Kubernetes clusters using Docker containers. By abstracting a cluster node within a Docker container, Kind provides the necessary tooling for this purpose. This abstraction relies on a pattern called "Docker inside Docker" (DinD), which allows you to run Docker containers within another Docker container, thus creating a nested containerization setup. DinD is commonly employed when managing containerized environments, such as building or testing Docker images, which aligns with Kind's functionality in setting up local Kubernetes clusters.

![kind-Kubernetes-IN-Docker](https://cdn.sanity.io/images/yvzuzc4g/production/39a9c168f2252c9369613f13e2aaca4aa3bd7467-2554x1612.jpg)

To create a Kubernetes cluster using Kind, the following steps are taken:

1. Kind checks if Docker is installed and installs it if necessary.
2. It creates a Docker image for the Kubernetes control plane (CP), responsible for managing the cluster.
3. Docker images are created for each Kubernetes node, containing the necessary Kubernetes binaries and files. These node images are based on the `kindest/node` image, which provides Kubernetes, `systemd`, and other required binaries for deploying Kubernetes within the container. The `systemd` service forwards journal logs to the container TTY.
4. The CP and node containers are then started.
5. The Docker containers are interconnected to form the Kubernetes cluster.

Once the Kubernetes cluster is successfully created, Kind provides you with the cluster's name. You can then use the `kubectl` command to interact with the cluster. Each cluster is identified internally by a Docker object label key, while each node container is identified with `cluster-name/ID`.

# Setting up Kubernetes Cluster with Kind

Kind is a set of go packages and docker images so you need go (1.17+) and docker installed before you can set up kind.

```bash
 $ go install sigs.k8s.io/kind@v0.18.0 
```

Once set up, create a cluster using

```bash
$ kind create cluster

Creating cluster "kind" ...
 ✓ Ensuring node image (kindest/node:v1.26.3) 🖼 
 ✓ Preparing nodes 📦  
 ✓ Writing configuration 📜 
 ✓ Starting control-plane 🕹 
 ✓ Installing CNI 🔌 
 ✓ Installing StorageClass 💾 
Set kubectl context to "kind-kind"
You can now use your cluster with:

kubectl cluster-info --context kind-kind

Have a question, bug, or feature request? Let us know! https://kind.sigs.k8s.io/#community 🙂
```

You are now ready to access the cluster from the same host. To share access to the cluster, you need to share the location of the cluster and the credentials to access it. The setup required [can be non-trivial](https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster/).

## Creating Multiple Clusters

You can easily create multiple clusters using the `—name` parameter with the `kind create cluster` command:

```bash
$ kind create cluster --name kind-test-2
Creating cluster "kind-test-2" ...
 ✓ Ensuring node image (kindest/node:v1.25.3) 🖼
 ✓ Preparing nodes 📦
 ✓ Writing configuration 📜
 ✓ Starting control-plane 🕹️
 ✓ Installing CNI 🔌
 ✓ Installing StorageClass 💾
Set kubectl context to "kind-kind-test-2"
You can now use your cluster with:

kubectl cluster-info --context kind-kind-test-2

Thanks for using kind! 😊
```

You can also use the `kind get clusters` command to get a listing of all the clusters you have created:

```bash
$ kind get clusters
kind
kind-test-2
```

## Deleting Kind Clusters

Kind allows you to delete clusters effortlessly. To delete a cluster, simply use the `kind delete cluster` command with a `—name` parameter. Note that if the `--name` parameter is not provided, kind tries to delete the cluster named `kind` by default

```bash
$ kind delete cluster --name kind-test-2
Deleting cluster "kind-test-2" ...

$ kind delete cluster
Deleting cluster "kind" ...
```

## How can Kind improve Security Posture?

Kind enables the creation of sandbox environments by setting up local Kubernetes clusters specifically for development and testing purposes. These sandbox environments provide isolation where developers can safely experiment, debug, and test their applications without affecting the production infrastructure.

Benefits of Kind as a Security Posture:

- Limits the attack surface as there are fewer entry points for external attackers
- Provides a controlled testing environment for local deployment
- Kind's YAML files make it easier to replicate cluster environments
- Compatible with all Docker-based security tools

# Applications of Kind

## Local Development

Kind is typically used for the local development of applications that are deployed on a cluster. For e.g., developers working on an application that in production is deployed on a cluster of 3 nodes shouldn’t need to create a local cluster with 3 nodes. With the same configuration files etc. that are used for setting up a 3-node cluster, developers can set up a 3-container cluster on their development machines to develop and test in a near-production environment.

## Continuous Integration

Similar to the application above, Kind is used for creating, deploying clusters on the fly for running automated tests, and then destroying the cluster when done. It not only saves the cost of nodes but is also time efficient.

At Adaptive, we leverage Kind for access management.

## How Adaptive Leverages Kind

Adaptive provides privileged access management to fast-moving teams within organizations. Organizations that have relied on bastion hosts to gate access to their infrastructure can use Adaptive to scale their access management requirements.

Adaptive leverages Kind to set up bastion hosts on the fly for organizations that do not have a K8s setup. Each dynamically created bastion is optimized for accessing a particular infrastructure resource with the necessary pre-installed tooling. With Adaptive, additional access policies such as time to live and user authorization can be configured and enforced on each container.

![Kind-at-Adaptive](https://cdn.sanity.io/images/yvzuzc4g/production/4bfd8b3a4fe59c2f6b125f13c778615f66d94b6f-1195x649.jpg)

Getting started with Kubernetes in Docker (Kind)

# How to SSH into Docker Container?

Docker containers can simplify the deployment of small services or monoliths. Docker, mostly, provides a lightweight and portable solution that can run on any system. But sometimes either to debug or fix a mess, one might have to access the container directly. While containers are designed to be self-contained and isolated, there are ways to access the container’s shell. To know more about docker, you can read [here](https://docs.docker.com/get-started/overview/).

Can you ssh into a docker container? Yes, but should you? 

That will depend on the constraint levied on your system. Each solution has its mix of security and ease of access. In this article, we will cover 3 ways to ssh into a docker container.

## Accessing a docker container, using docker exec:

The easiest way to access a live container would be to use `docker exec`. 

```bash
$ docker exec -it <container-id> /bin/bash
root@<container-id>:/#

# If you do not know the container id your container
# list out the running container like so:
$ docker container ls
CONTAINER ID   IMAGE           COMMAND                  CREATED      STATUS             PORTS                                       NAMES
85d84ef9dc32   postgres:11.3   "docker-entrypoint.s…"   2 days ago   Up About an hour   0.0.0.0:5432->5432/tcp, :::5432->5432/tcp   article_test_1
```

This is the recommended method for accessing the container. It's secure, simple, and traceable via Docker logs. However, in some cases, a container may disable access via `bash` or `sh`, or you may not have access to the `docker-host`. In such situations, you can always fall back on the traditional method of using *ssh*.

## Accessing a docker container, using SSH:

While `docker exec` is the recommended way, SSH also has its place. Access via SSH is necessary for testing infrastructure automation or provisioning scripts before running them on production. There are many ways to authenticate with an SSH server, including simple username-password, public-key authentication, Kuberos, and two-factor authentication. We will cover two of these methods:

### 1. Using Username and Password

If the ssh-agent in your docker container, accepts password access then ssh access to the container is as simple as:

```bash
# `remotehost` is the host/ip of your docker container instance
$ ssh <username>@<container-ip>
```
You can find an example Dockerfile that runs an ssh-agent with a specified username/password

```bash
FROM ubuntu:latest

RUN apt-get update && \
    apt-get install -y openssh-server sudo && \
    rm -rf /var/lib/apt/lists/*

RUN useradd -rm -d /home/ubuntu -s /bin/bash -g root -G sudo -u 1000 test && \
    echo 'test:supersecretpassword' | chpasswd

RUN mkdir /var/run/sshd

EXPOSE 22
CMD ["/usr/sbin/sshd", "-D"]
```

You can access this container using ssh like:

```bash
$ docker run -p 2023:22 -d sshtestcclear
$ ssh -p 2023 test@localhost
test@localhost's password: ********
# you will be prompted to enter password for user `test`
# `supersecretpassword`
```

If the container is not deployed on your localhost, you can query its IP using the following command:

```bash
$ docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' <container_id>
172.18.0.2
```

### 2. Using Public Key

You will need to generate a ssh key pair. The public key will be added to the container and the private key would be used by you to authenticate your identity to the container’s ssh-agent. Let’s suppose the names of those are, key.pub and key ( to learn more about generating these keys check this [article](https://git-scm.com/book/en/v2/Git-on-the-Server-Generating-Your-SSH-Public-Key).

```bash
FROM alpine:latest

RUN apk add --update --no-cache openssh
RUN addgroup -S test_user_group && adduser -S -G test_user_group test_user

RUN mkdir -p /root/.ssh

# Build image with public key added to authorized_keys file
# of the container
COPY key.pub ./root/.ssh/authorized_keys
# Restrict access for keys to owners of file only
RUN chown test_user:test_user_group /root/.ssh/authorized_keys && chmod 600 /root/.ssh/authorized_keys

RUN ssh-keygen -A

EXPOSE 22

# log to stderr using "-e"
CMD ["/usr/sbin/sshd","-D"]
```

```bash
# build the docker image
$ docker build -t ssh-agent-in-docker .
# run the docker image, exposing port 2023 on host to ssh port in container
$ docker run -p 2023:22 ssh-agent-in-docker
```

```bash
# now you can access the container using ssh by using private key
$ ssh -i /location/to/key -p 2023 test_user@localhost
```

But what if you don’t have access to docker-daemon and the container is running on a network not exposed to you?

## Accessing a docker container, via another docker container:

Imagine a situation where you want to access a container running on your home lab from an airport or another location. If you lack a public and static IP for your home network, and the airport Wi-Fi network is not part of your home network, you cannot access the container from outside without a complex private network or VPN setup. Exposing your entire home network via a public IP would also attract negative attention.

Instead of directly exposing the external interface of your home network, you can use a public server as a bridge between you and the container running on your home network. This is because a public server will have a public IP that can be accessed from anywhere.

An example of this is [rsshd](https://github.com/efrecon/rsshd), which provides a minimal implementation of this. To use it, follow these steps:

1. On a public server (e.g. `server.public`), run the Docker container

```bash
$ docker run -it --rm \
    -p 2222:22 \
    --name rsshd \
    -p 10000-10100:10000-10100 \
    -e PASSWORD=secret \
    -v /opt/keys/host:/etc/ssh/keys \
    -v /opt/keys/clients:/root/.ssh \
    efrecon/rsshd

chpasswd: password for 'root' changed
Server listening on 0.0.0.0 port 22.
Server listening on :: port 22.
```

2. Creating a Reverse Tunnel

This will run bridge on your public server. To access the container remotely via the reverse tunnel, you would first need to create a reverse tunnel on it, by:

```bash
$ ssh -fN -R 10000:localhost:22 -p 2222 root@server.public
```

3. SSH access via the reverse tunnel

Now a reverse tunnel (on the port) exists from the container (in the home network) with the container/bridge running on the public server. You can now just ssh to the public server on the port.

```bash
$ ssh -p 10000 root@server.public
The authenticity of host '[server.public]:10000 ([::1]:2222)' can't be established.
ED25519 key fingerprint is SHA256:HagFEp3Lxjk4DY/8Xm3gRuMvuYiXchlNZSWKXLGfJlU.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[server.public]:2222' (ED25519) to the list of known hosts.
root@localhost's password:
Welcome to Alpine!

The Alpine Wiki contains a large amount of how-to guides and general
information about administrating Alpine systems.
See <http://wiki.alpinelinux.org/>.

You can setup the system with the command: setup-alpine

You may change this message by editing /etc/motd.
```

**Note:** If you manage your container using Podman or Portainer, you can find more information about their exec functions [here](https://docs.podman.io/en/latest/markdown/podman-exec.1.html) and [here](https://docs.portainer.io/user/docker/containers/console), respectively.

## Accessing Docker Containers Using Adaptive

As teams get bigger, accessing containers within private networks can become increasingly challenging due to heightened access restrictions. It's possible to encounter situations where direct access to the network or the necessary keys to connect to a container is limited. Adaptive makes it easier to access containers in all such cases.

With Adaptive's Access Management platform, you can SSH or access a container's shell using a simple command:

```bash
$ adaptive connect <endpoint_name>
```
where `<endpoint_name>` is an Endpoint connected to your Container or VM.

How to SSH into Docker Container?

In today's rapidly evolving business landscape, enterprise-level information security has become a top priority for businesses and their customers. SOC 2 compliance is a critical benchmark for affirming the security of your services, and it provides clients with evidence from an auditor who has seen your internal controls in action, operating in accordance with the AICPA.

Our customers rely on our platform to protect access to their key infrastructure like servers and databases. Thus, we believe it is our responsibility to go above and beyond to make sure their information and data is secure with the industry standard techniques and processes.

The SOC 2 audit is acknowledged across the industry as one of the most stringent benchmarks for information security compliance worldwide. The American Institute of Certified Public Accountants (AICPA) defines the System and Organization Controls (SOC) for this purpose.

At Adaptive Automation Technologies, we are proud to announce that we have achieved **SOC 2 Type I** compliance in accordance with AICPA standards for SOC - Service Organizations also known as SSAE 18. Achieving this standard with an unqualified opinion serves as third-party industry validation that Adaptive Automation Technologies provides enterprise-level security for all the customer data secured safely in the Adaptive Automation Technologies System.

Our security policy can be found [here](https://adaptive.live/security).

Our SOC 2 efforts were led by me with support from my team. Adaptive Automation Technologies underwent an audit by industry leader, [Prescient Assurance](https://www.prescientassurance.com/), for security and compliance attestation of our B2B and SAAS services. Prior to engaging with its auditors, the company utilized [Drata](https://drata.com/) as its compliance automation platform. This achievement of SOC 2 Type I compliance indicates that Adaptive Automation Technologies follows the highest standard of security and compliance, providing enterprise-level security for all of its customer data. 

The successfully completed SOC 2 Type I audit report serves as third-party industry validation of the company's security measures and demonstrates to all current and future customers of Adaptive Automation Technologies that we manage our data in highly secure and compliant ways.

Adaptive has completed SOC 2 Type I Audit

## **What is Privileged Identity Management (PIM)?**

Privileged Identity Management (PIM) enables organizations to manage who (identity) can access what resources within an organization. These resources could include databases, servers, SSH keys, and source code repositories. 

A PIM solution acts as a single repository of employees and resources within your organization. And provides a single dashboard for managing what resources any given employee can access. 

## **Features of Privileged Identity Management**

Key features of Privileged Identity Management include:

- Limited access to users
- Automatic password generation, rotation, and credential management
- Just-in-time privileged access to resources
- Multi-factor Authentication (MFA)
- Time-bound access to privileged accounts
- Centralized management console such as Adaptive to manage all privileged accounts
- Access evaluations to make sure users still require roles
- Allows users to request privilege elevation for specific tasks

## **Risks of Unmanaged Privileged Identities**

When the size of an organization increases, the number of resources and users increases as well making it difficult to keep track of all the privileged identities. Unmanaged privileged identities pose many high-level risks to organizations such as -

- Unauthorized access to organization's infrastructure and data
- Susceptible to malicious attacks by external threats
- Violations of regulatory compliance requirements
- Exploitation by insider threats
- Lack of accountability for actions taken by privileged users

Overall, unmanaged privileged identities possess risks and be potential threats to any organization’s security posture. Implementing a PIM solution can be of help to manage privileged identities and reduce risks to the organization.

## **Benefits of Privileged Identity Management**
![Benefits of PIM](https://cdn.sanity.io/images/yvzuzc4g/production/85098934e04a1f6e8aa4cbb5228546d2dd6b7beb-2553x1216.jpg)
- **Simplifies access**
    
    PIM makes it easier to grant access privileges to specific users within the organization. The privileged users can access resources, request for privilege elevation, and even regain access in case of lost credentials.
    
- **Helps in decision-making and audit trail**
    
    PIM gives a centralized console to monitor who has access to what resources right now, when was the access granted, and what is the time period for which the user has access to any resource. Furthermore, it provides detailed audit logs giving information about all the activity and changes made by the privileged user.
    
- **Regulatory compliance**
    
    PIM helps organizations meet the regulatory compliance requirements described by HIPAA, GDPR, SOC 2, etc. These compliance requirements direct organizations to limit access to confidential information to a select few privileged individuals only.
    
- **Reduces the cost of auditing and IT**
    
    Under PIM, organizations have pre-set frameworks in place to handle all user access requests and grant permissions. This improves IT operation efficiency, streamlines the auditing process with direct reports, and also automates compliance.
    
- **Reduced risks due to inactive accounts**
    
    PIM involves managing the risk involved with all the privileged accounts and monitoring them across the organization. This helps easily track and revoke access to inactive accounts that can be used by external threats to gain unauthorized access.
    

## **Limitations of Privileged Identity Management**

- **Restricting privileges can reduce productivity**

   Restrictive access to privileged accounts can lead to employees’ reduced productivity and efficiency due to additional steps required to gain access. The delay in access and loss of time will impact the user experience as well.

- **Forgotten privileged accounts and assets become backdoors to an organization’s infrastructure**

   As an example, when an employee departs a company, their privileged access to corporate systems and networks needs to be disabled immediately.

- **Shared credentials complicate attribution, compliance, and auditability**

   For convenience, teams inside a business, particularly those in IT, frequently exchange privileged credentials like admin accounts for convenience. But it can be difficult for a company to determine who really accessed the resource.

- **Manual credential management can be a source of costly errors**

   Scaling of Privileged Identity management across larger companies can be difficult due to the involvement of different departments, hundreds of users, privileged accounts, and their credentials. Manual credential management practice isn’t a great way to manage access in such cases and can be counterproductive and costly for the organization.

- **Permanently embedded credentials are susceptible to being exposed**

   A general practice followed by developers to put credentials and other secrets in their codes or files for ease of use can prove to be risky. These files, codes, or scripts can expose credentials to public view if left unsecured.

## **Privileged Identity Management Implementation**

The primary actions you may take to deploy Privileged Identity Management in your business are listed below:

- Evaluate the need for an organization-wide PAM implementation
- Identify persons who will identify suitable PAM solution and oversee its implementation
- Define organization-wide access policies
- Identify best practices and tools to ensure that defined policies are followed

## **Differences between IAM, PIM, and PAM**

There is plenty of overlap between the functions of [IAM](https://www.adaptive.live/blog/identity-and-access-management-iam-explained), PIM, and PAM, and the terms are used interchangeably. With PIM, the focus is on defining who (identity) can do what. IAM lets us define who can do what and also supports fine-grained permissions using attributes, roles, groups, etc. With PAM the focus broadens to also include who is doing (accessing) what. The latter therefore also involves monitoring and audits.

## **How Adaptive can help**

Adaptive provides seamless infrastructure access to teams and a Privileged Access Management platform for admins in a single product. It includes:

- **Privileged Access Management for all infrastructure resources**
- **Continuous Compliance through auto-compiled audit logs**
- **Access Policies to proactively protect your organization**


Ultimately, controlling access to various resources is crucial for safeguarding a company's expanding infrastructure and Adaptive makes it easy to do so.

Privileged Identity Management (PIM) : A Brief Guide

## What is the Principle of Least Privilege?

We live in an age of hyperconnectivity and ubiquitous computing, which has led to the emergence of advanced cyber threats. News reports of massive data breaches affecting businesses from fledgling startups to large corporations have become increasingly more common. Protecting sensitive information and making their security infrastructure more robust, has thus become one of the, if not **THE** primary concern of organizations all over the world.

In mitigating these risks that organizations are faced with on a constant basis, The Principle of Least Privilege plays a crucial role. The Principle of Least Privilege (PoLP) emphasizes limiting a user's access to only the minimum set of resources required to complete a task (least privilege). By following the Principle of Least Privilege, organizations can reduce the probability of unauthorized access, and minimize the blast radius in the event of a breach.

## How does the Principle of Least Privilege Work?

PoLP works by limiting user access and permissions to only the absolute minimum required to perform their tasks. Here, the user can be a human user or any process or entity that requires access to the resources under question. Limiting access this way reduces risks like Privilege Creep, where users end up accumulating privileges over time, as they work on new tasks or move to new roles or departments, requiring new privileges, while older, unnecessary privileges may remain un-revoked. In following the Principle of Least Privilege, users are granted access to resources on a strictly need-to-know basis, which can prevent unauthorized access.

Some well-known strategies for implementing PoLP include:

1. **Just-in-Time Privileged Access Management (JIT PAM):**
Where a user is **temporarily** granted privileges to resources that are essential to perform a task, for no longer than is necessary to perform a task. Thus, the privilege is restrictive in scope as well as in time. Privilege Bracketing works on this principle.

2. **Role-Based Access Control (RBAC):**
Where roles are assigned to users based on job function. Under this role, the user has access only to those resources defined by the role. As such, individual users are not directly assigned permissions, and inherit permissions from their roles.
For example: Under RBAC, an employee in the Payroll department of an organization who wants to prepare monthly summaries using a payroll table in the database will be assigned the `payroll` role, which may provide read-only access to only that table.
![image](https://cdn.sanity.io/images/yvzuzc4g/production/6c90c5815715766b9ff5134a6d57312940f24336-2554x1547.jpg)

## Principle of Least Privilege in Action

Examples of enforcing the Principle of Least Privilege can be found on many levels and across multiple subsystems of IT infrastructure. Some of the more widely known practical applications can include filesystem permissions on Linux or UNIX-like OSes, user privileges in Relational Database Management Systems such as MySQL, and more recently, Identity and Access Management (IAM) systems on cloud platforms like AWS and Google Cloud.

### File and directory permissions in Linux

Linux file permissions allow for the implementation of the Least Privilege Principle by restricting user/process access to files and directories. Every file and directory has read, write, and execute permissions at owner, group, and other levels.

### IAM in Amazon Web Services (AWS)

AWS [Identity and Access Management (IAM)](https://adaptive.live/blog/identity-and-access-management-iam-explained) enables the implementation of the Principle of Least Privilege by providing control over user permissions to AWS resources such as EC2, S3, Lambda, and more. Within the IAM console, administrators can create fine-grained policies that specify the actions that a user or group can perform on AWS resources. Policies can be tuned to grant users and other AWS resources only the necessary permissions, minimizing the potential damage from security breaches or unauthorized access.

### Databases

The Principle of Least Privilege can be implemented on popular RDBMS systems like MySQL, Postgres, Oracle, and Microsoft SQL Server using the `GRANT` statement, which can be used to define read, write, update, delete, drop, and alter access to tables for database users.

These RDBMS platforms also provide more fine-grained row-level security e.g. Postgres' Row-Level Security feature. Row-level access control can be implemented by using views, where only the necessary rows in a table that the user needs access to can be stored as a view, and providing read access to the user to these views, instead of the underlying table itself.

Among NoSQL databases, MongoDB provides an implementation of Least Privilege through RBAC described above. A database administrator can define roles, which can be applied at the level of an individual user, or groups of users.

## Best Practices for Implementing the Principle of Least Privilege (PoLP)
![image](https://cdn.sanity.io/images/yvzuzc4g/production/b8c2e4bb53142657543f633f6c12e637f05e4770-2554x1223.jpg)
It is recommended to perform a thorough audit of your organization's existing security infrastructure before you get started with implementing the Principle of Least Privilege. This includes assessing existing users, resources, processes, and the security risks and mechanisms involved. After this initial assessment, we can follow these best practices:

1. **Define user roles and access levels:** After identifying the different types of users who will access the system and the resources they access, define roles and access levels for each role and the privileges associated with those roles. This is Role-Based Access Control (RBAC) in action. Several standards for implementing RBAC exist including the National Institute of Standards and Technology's NIST RBAC system.
2. **Limit access based on need:** Minimize access to the bare minimum number of resources required by the user, an additional layer of security can be added by making the access time-bound.
3. **Authentication and authorization controls:** Robust authentication mechanisms, such as multi-factor authentication (MFA), should be employed, by which only authorized users can access resources.
4. **Monitoring:** Effective monitoring involves the use of various tools to identify potential security risks and prevent incidents. Intrusion detection and prevention systems, log management solutions, and firewalls are examples of such tools. These tools are essential for organizations in proactively monitoring their systems and infrastructure, and preventing breaches.
5. **Regular reviews and policy updates:** Regularly review and update access policies and user roles as users, systems, and processes in the organization change. Ensuring that privileges remain appropriate and up-to-date can help prevent security issues like Privilege Creep from arising over time.

The goal of every CISO (Chief Information Security Officer) should always be to **Minimize Access to Maximize Security**

## Benefits of Implementing the Principle of Least Privilege

1. **Risk reduction:** Implementing the Principle of Least Privilege minimizes the risk of unauthorized access or misuse of resources that are critical to an organization. Well-defined, tightly controlled access policies can minimize the attack radius in the event of a security breach.
2. **Easier compliance practices:** Adhering to PoLP enables organizations to meet regulatory compliance requirements by ensuring that access to sensitive information is strictly controlled and monitored.
3. **Improves system performance:** As an added advantage, limiting access can improve system performance by reducing the number of users and processes accessing critical systems and data.
4. **Simplifies access management:** If implemented well, the Principle of Least Privilege enables organizations to simplify access management by reducing the number of roles and permissions required.
5. **Saves costs:** Implementing PoLP invariably results in an organization avoiding financial, and reputational costs as they minimize the risk of security breaches and the fallout occurring from them.

## Relation to Zero-Trust Architecture (ZTA)

Zero-Trust Architecture or the Zero-Trust Security Model assumes that all access to an organization's resources must be subject to continuous verification and authentication, and no user or entity trying to access these resources should be automatically trusted. In short, "Never Trust. Always Verify".

The Principle of Least Privilege draws parallels to ZTA with regard to minimizing access using Role-Based Access Control and Just-In-Time Access Management implementation.

What is the Principle of Least Privilege (POLP)?

## What is HIPAA Compliance?

Health Insurance Portability and Accountability Act or more commonly known as HIPAA is a regulatory law incorporated in 1996 by the HHS, to protect and safeguard the privacy and security of each individual's Protected Health Information.

The Office of Civil Rights (OCR) within the U.S. Department of Health and Human Services (HHS) is responsible for ensuring all the Covered Entities and their Business Associates dealing with patients’ personal and healthcare information comply with the different HIPAA rules. The OCR does investigate and impose monetary fines in case of non-compliance with these HIPAA rules by any Covered Entities or Business Associates. OCR maintains a website called the [Breach Notification Portal](https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf) or OCR's ‘Wall of Shame’ that posts a list of all the breaches of unsecured protected health information that are currently being investigated.

### What is Protected Health Information?

Protected Health Information or PHI is any data collected by the CE related to any individual's health or healthcare services provided that can be used to identify the individual. PHI can be data in electronic or paper-based form as well.

This includes medical records, scan reports, test results, billing information, and other personal data like contact numbers, social security numbers, addresses, and credit card details.

## Why is HIPAA important for organizations?

HIPAA safeguards the PHI of individual patients. But the question at hand is why is it important to safeguard this information. And how is it important to the organizations?

The Healthcare industry is a growing target for online hacks and information breaches with this sensitive protected health information being very valuable to hackers. How valuable you may ask? Well, the average cost of a [healthcare data breach](https://www.ibm.com/reports/data-breach) is about $10 million in 2022 but, there have been much more expensive data breaches in the past that have cost as high as [$400 million](https://www.hipaajournal.com/2022-healthcare-data-breach-report/) to the organization.

According to The HIPAA Journal, the year 2022 alone saw close to 700 healthcare data breaches that leaked **51.9 million** individual records combined in the US. Hence, complying with HIPAA is needed to safeguard the protected health information of the patients and avoid leaks of their confidential PHI records. 

A few other advantages of HIPAA compliance to any organization are -  

- Avoiding penalties from OCR for non-HIPAA compliance
- Enhanced cybersecurity and increased protection from a data breach
- Increased patient trust in the organization
- Easier transfer of data using electronic copies of PHI
- Reduced medical errors in patient diagnosis and information transfer

## HIPAA Compliance Checklist

![image](https://cdn.sanity.io/images/yvzuzc4g/production/10a2914d1ad2208cc5c28897e46eaa921b683d75-1702x904.png)

Staying compliant with HIPAA can seem tedious at times but it is very important for all the covered entities and business associates dealing with PHI. HIPAA compliance requires a close understanding and implementation of the HIPAA Privacy Rule, Security Rule, and Breach Notification Rule as applicable to the entities. This is where a HIPAA Compliance Checklist will be of help.

Here is the 8-step HIPAA compliance checklist to help organizations get HIPAA compliant - 

### 1. Understand the HIPAA Privacy and Security Rule

HIPAA Privacy and Security rules are both very closely related. Together they set rules for entities on protecting patients’ PHI and also instruct them about the safeguards to be put in order to protect this sensitive information.

HIPAA Privacy rule outlines the patient’s rights to protect their health records and other identifiable information. It also outlines how this data can be used or shared by entities only for authorized purposes.

HIPAA Security rule on the other hand dictates how the e-PHI of the patient can be created, received, used, or maintained by a covered entity. It also requires covered entities to implement Administrative, Physical, and Technical safeguards to ensure the confidentiality, integrity, and security of the e-PHI.

### 2.  Determine if the Privacy Rule affects you or not

The Privacy rule primarily applies to all the covered entities (Health plans, health care clearinghouses, and health care providers dealing with PHI - according to the HHS), hence you need to be sure if your organization is a covered entity or not. Covered Entities under the HIPAA privacy rules are required to protect all forms of PHI, report HIPAA violations, and pay fines in case of non-compliance.

Though not directly stated but business associates also need to comply with the Privacy rule for their associated covered entities. Business associates need to keep in mind the patient’s rights concerning their PHI and how it should be used at all times. The covered entities must have a Business Associate Agreement (BAA) with all its partners and the rules regarding maintaining PHI security and overall HIPAA compliance by the BAs should be clear in this agreement.

### 3. Protect the right types of patient data

It is important to know what type of data needs to be protected under the HIPAA Privacy rule. HIPAA privacy rule enforces the protection of PHI which is defined as “Individually identifiable health information” of the patients. 

Not all the information your organization collects is classified as PHI. It is important for organizations to identify what part of their collected data is actually PHI. Only this data needs to be extra protected using appropriate security measures and safeguards. Also only authorized individuals should be able to access this sensitive information.

![image](https://cdn.sanity.io/images/yvzuzc4g/production/c501af666b0f867fa82924dfc8e7510c7504491f-2554x2419.jpg)

### 4. Conduct a Security Risk Assessment

All covered entities should conduct an annual security risk assessment to understand the gaps in their security system. The [Security Risk Assessment Tool](https://www.healthit.gov/topic/privacy-security-and-hipaa/security-risk-assessment-tool) by The office of the National Coordinator for Health Information Technology can be of great help for this assessment.

A periodic risk assessment helps monitor all the security measures implemented by the entity and find areas where the organization’s stored PHI can be at risk. It helps organizations understand if their security measures are compliant with the standards required under the HIPAA security rule.

### 5. Avoid potential HIPAA violations

HIPAA violations can occur in numerous ways, the most widely known of them are of course external hacks or data breaches, but surprisingly they are not the most common violations. In fact, the top 5 most common HIPAA violations that occur are the internal ones that can be easily prevented by organizations.

The [top 5 HIPAA violations](https://www.hipaajournal.com/common-hipaa-violations/) are - 

- Accessing patient health records for unauthorized reasons
- Failure to perform a regular organizational risk assessment
- Lack of risk management process for the risks identified
- Failure to enter into a Business Associate Agreement with all partners
- Insufficient access control over ePHI

It is important to prevent these common HIPAA violations. Addressing all the security gaps, implementing technical safeguards such as encrypting data, using unique passwords, restricting access to PHI, and training all users about staying compliant, etc. helps avoid such violations.

### 6. Implement the Administrative, Physical, and Technical safeguards

Under the HIPAA Security rule, it is important for organizations to -

- Protect the PHI from any reasonably anticipated external threats
- Ensure only permissible use and disclosure of PHI takes place
- Training the workforce about being compliant
- Implement safeguards to ensure PHI security

HIPAA Security rule requires organizations to implement appropriate Administrative, Physical, and Technical safeguards in order to protect PHI data.

1. **Administrative Safeguards** - All the administrative actions involved in the development, deployment, and implementation of the ePHI security along with the management of the workforce dealing with ePHI are termed Administrative Safeguards. Examples of standard administrative safeguards are workforce security training, business associate agreements, conducting risk assessments, assigning a privacy official, PHI access policies, etc.
2. **Physical Safeguards** - The physical measures and procedures put in place to guard the organization's ePHI and its related buildings, infrastructure, and equipment against any unauthorized intrusion come under Physical Safeguards. A few examples of physical safeguards are security cameras, alarms, protection of portable devices (USB, Laptops, etc.), security plans for physical entry into record rooms, maintenance records, etc.
3. **Technical Safeguards** - The technology, and the policy and procedures attached to handling such technologies for the protection of ePHI are termed Technical Safeguards. It is the most important of the three safeguards to ensure the protection of ePHI from external threats present. Examples of technical safeguards are encryption and decryption of data, data backup and storage, automatic logoff, access controls to ePHI, etc.

### 7. Detailed documentation of HIPAA compliance efforts

It is always better to document all the efforts made by the organization toward being HIPAA compliant. Constant documentation of all the essential HIPAA-related activities helps maintain transparency, address gaps in security, and mitigate risk.

This documentation can include OCR audit relevant documents such as policies and procedures, written and electronic communications, and actions requiring written records starting from the first draft to all the versions changed over time. All the documents holding PHI and detailed policies about disclosing and safeguarding PHI need to be kept for at least 6 years time. Also, documents such as audit logs, risk management process, BAA and other agreements, training records, list of vendors having access to PHI, etc. are relevant and valuable in case of a violation.

### 8. Report any breach of data immediately

In case of a data breach, it is the responsibility of the organization to have a plan of action. The organization must notify the OCR within 60 days of discovering the breach in cases when the breach affects more than 500 people. The organization also needs to inform the local media and all the people affected by the breach and open an internal investigation about the incident.

The OCR investigates all the breaches affecting 500 or more people and such breaches are listed on their Breach Notification portal as well. This 2-way investigation of breaches can help identify the reason for the breach faster and the security gaps within the organization can be fixed helping the organizations maintain their HIPAA compliance.


### Final Thoughts

In conclusion, staying HIPAA compliant is critical for any organization dealing with PHI but it is not a one-time task. Achieving HIPAA compliance and maintaining it over time is equally important. It is an ongoing continuous effort for organizations to stay HIPAA compliant.

For all those who are looking to get HIPAA compliant for the first time, the above HIPAA compliance checklist will be of great help. While for organizations that are already compliant, following the checklist will help review their existing policies, safeguards, and documentation in order to stay HIPAA-compliant with the changing environment.

HIPAA Compliance Checklist 2023: The 8-step Easy Guide

## What is a Bastion Host?

A Bastion host allows authorized users to access a private network through an external network, such as the internet. The bastion host becomes the sole ingress path to those internal resources when it is placed outside the firewall or in a DMZ. Access control is made simpler to monitor while reducing the attack surface.

### How to create an AWS Bastion Host?

Below are the brief steps showing [how to set up an AWS Bastion Host](https://adaptive.live/blog/how-to-set-up-an-aws-bastion-host-or-a-jump-server) for your infrastructure.

1. Set up a new server to be used as a bastion host.
2. Configure firewall rules on the server to allow inbound SSH connections from the internet.
3. Configure firewall rules on all other internal servers to allow inbound SSH connections from the bastion host only. 

## Primary Use Case of Bastion Host

Secure Remote Access is the main use case of a bastion server.

The bastion host is located on its own private subnet and has an organization-facing/internet-facing IP address. Only the organization’s IP or allowed address ranges are accepted by bastion for incoming connections. Access from the bastion to the protected subnets is restricted by the rules specified in the ACLs, allow lists, and other network-level access rules. This adds an additional layer of security.

However, there are multiple ways you can re-purpose the same bastion host to serve multiple use cases. We explore a few of them below.

## Alternative Use Cases of Bastion Host

![image](https://cdn.sanity.io/images/yvzuzc4g/production/2b8c7bc6041e6242ab7a40aebe7e5c7689691f83-2554x1760.jpg)

### Use case 1: VPN Alternative

Virtual Private Networks are a dwindling technology in recent times. It was established, to connect remote centers of an organization to a centralized data server through a network, most commonly the internet. 

An ingenious ‘secure-parameter’ solution to offer a few trusted employees, contractors, and third-party personal remote access to the system, the usefulness of VPNs decreased as the organizations’ infrastructure was decentralized, cloud-enabled, and remote-working was established as a prominent working method. Nowadays, most employees hit the VPN gateway for remote access exposing the gateway’s presence over the internet, to anyone running a scanning application. Increased visibility translates to increased threats. A simple patched VPN appliance undermines the infrastructure, putting the security of the organization at a risk.

To combat the weaknesses of VPNs, organizations have started searching for secure alternatives and Bastion hosts are gaining widespread popularity as an alternative to VPN.

One of the downsides of a bastion host is that you might have to expose the server to the internet. This can lead to the port knocking issue, where various random requests on the SSH port (standard or non-standard) are received. To prevent this, organizations might again need to use a VPN to protect it. Another way to prevent this is to use an outbound-based reverse tunnel.

The benefit of reverse tunneling is that it allows a user to connect peer-to-peer as compared to a VPN where you have to give access to a subnet. You can utilize that already existing connection to create a new connection from your local computer back to the remote computer via reverse SSH tunneling. Other tools that can be used to achieve this are ngrok, SOCKS5, and [Adaptive](https://adaptive.live).

![image](https://cdn.sanity.io/images/yvzuzc4g/production/4b52199882e28e9c608e9221634140d76d4cfc43-2553x1410.jpg)

### Use case 2: Authentication Gateway

It is a security mechanism that is used to manage access to a private network by authenticating and authorizing users before allowing them to connect to the bastion host. 

Implementing this paradigm is easy after setting up the reverse tunnel. The gist involves setting up an authentication service (commonly called a gateway) on the Bastion Host.  The gateway must be configured to handle services of user identification, authentication, and authorization. Of course, the reverse tunnel has to be established following the steps described in the previous sections. Make efforts to note the outbound port of the gateway, as this is the destination port for the host.

This sets up a secure layer of abstraction where remote clients should first connect to the Bastion Host using SSH and only after they are authenticated by the gateway can they access the server. Ensuring that only authorized users can access the servers, ensuring that data breaches and device-patch breaches prevalent in VPNs are prevented.

The pattern offers a reverse proxy to reroute or redirect requests to the endpoints of your internal microservices. For client applications, an API gateway offers a single endpoint or URL, and it internally routes the queries to internal microservices. By obscuring some implementation details, a layer of abstraction is created. On top of the backend service, more features can be added, such as request and response transformations, endpoint access authorization, or tracing.

### Use case 3: Alternative to Internal Admin Tools

The core use case of using Bastion is that it can route multiple users through one host into various downstream resources. In large organizations, instead of giving full-scale access to the downstream resources, access to various scripts is given to users who can execute tasks like restarting a service, cleanup disks, etc.

A Bastion host can be used as an internal admin tool to provide a secure and centralized point of access for administrative tasks across the infrastructure. This approach can help improve security by reducing the number of entry points into the infrastructure and providing greater control over administrative access.

**How does it work?**

- An admin needs to install an execution engine in the Bastion. It could be python, ruby, lua, PHP, or bash.
- Once the executors are installed, you can persist the operations or internal scripts in the Bastion. Either you can manually upload it in the Bastion or you can set up a git repository that can be cloned and fetched.
- You can create an ACL on the scripts with `chmod`, `chown`, or `chgrp` where in you can specify if the user Alice can only execute scripts to restart DB but not restart the server.
- Enable SSH audit to capture logins.
- It is difficult to audit what scripts were executed by whom unless the history is also being captured and logged.

![image](https://cdn.sanity.io/images/yvzuzc4g/production/bf0003884853ad07346c7a12dc3949908a4b54bd-2554x1410.jpg)

Centralizing administrative tasks and scripts lead to higher productivity gain and a better security posture by reducing the number of entry points into the infrastructure.

### Use case 4: Alternative to File Transfers

Sharing huge files between teams and different stakeholders securely is often a challenge. One can use public cloud drive services for non-sensitive data, however, for sensitive data, a Bastion host can be an excellent candidate. 

**How does it work?**

An admin has to install a secure file transfer service such as SFTP, SCP, or FTPS. The Bastion host should be configured correctly e.g. the firewall allows appropriate incoming traffic.

With Bastion host, you can ensure authorized users can only access the files uploaded in the host via sftp service. You can ensure this by creating users for accessors and enforce fine-grain control via `chmod` and `chown.` Users can transfer files using scp or an equivalent file transfer service that is configured in the bastion host. 

One of the benefits of this setup is that monitoring and audit logs of the file transfers are available by default and can be found in the ssh audit logs.

![image](https://cdn.sanity.io/images/yvzuzc4g/production/00ed1001025fd22ef8052939f32cea9e55c53c9d-2554x1410.jpg)

### Use case 5: Alternative way to Share Resource Credentials

One can share resource credentials with bastion hosts by simply saving the credentials in the bastion host itself. As the organization’s downstream resources are protected by the Bastion and cannot be accessed outside the Bastion. It is ok to do this. This method has the following challenges - 

1. Credential rotation becomes painful as it has to be manually updated
2. Keeping track of what credentials are where in the bastion is fairly challenging
3. Users do see the real credentials

A better approach to sharing credentials via Bastion is via installing and configuring a secrets management system.

With a secret store, administrators can upload the credentials in the store. Configure a user in the bastion host that can authenticate with the [secrets management system](https://adaptive.live/blog/credential-management-explained-best-practices-and-the-future) and retrieve the credentials. You can grant access to the user configured in the bastion host. Once retrieved, accessors can use this credential to access the downstream resource.

Overall, this improves the security posture of an organization as it makes lifecycle management and rotation fairly easy. But, there is still some risk wherein the actual credentials to access the resources are still exposed.

### Use case 6: Alternative to Intrusion Detection

For this use case, the organization has to first install an intrusion detection system.

There are two ways Bastion can help with intrusion detection. 

1. Install and configure intrusion detection software: You'll need to install and configure intrusion detection software, such as Snort or Suricata, on the Bastion host to monitor network traffic and detect potential security breaches.
2. Configure the Bastion host firewall: Ensure that the firewall on the Bastion host allows incoming traffic on the appropriate ports for the intrusion detection software.
3. Configure the intrusion detection rules: Configure the intrusion detection rules to detect the specific types of activity that you want to monitor.
4. Monitor network traffic: With intrusion detection software in place, the bastion host can monitor network traffic and log any suspicious activity.
5. Set up alerts and notifications: Configure the intrusion detection software to generate alerts and notifications when potential security breaches are detected so that administrators can take appropriate action.
6. Investigate and respond to potential security breaches: When potential security breaches are detected, investigate the activity and take appropriate action to prevent further damage.

Additionally, organizations can use it as a honeypot for trapping hackers.

You can purposely expose the port so that it gets knocked by intruders. Collect their IP addresses and add them to the blacklist.

### Use case 7: Software Inventory Management

In an organization, it is essential to maintain an up-to-date software inventory and dependencies in order to maintain a good security posture and manage critical vulnerabilities. Unauthorized access often exploits an old and known vulnerability to gain access to various IT systems. A bastion host can play an important role in software inventory management as it has access to various downstream resources. A software inventory management system on bastion can be set up as follows: 


1. Install and configure an automation platform like Ansible, Puppet, or Chef, on the bastion host to manage software and user access across the infrastructure.
2. Allow outbound connections on the firewall so that the software updated can be downloaded from repositories. If the repositories are hosted locally or are known to users, then whitelist them.
3. Run the automation script to scan the software services and databases and check if they need an update.
4. Schedule the automation via cron job for daily, weekly, monthly, or quarterly scans and updates.

A bastion host can be used to streamline the management process and improve administrator overview over software updates. These processes help organizations achieve compliance and regulatory best practices without compromising productivity.

## Conclusion

As a work-from-home enthusiast, it is increasingly clear that the current workforce prefers remote working. As the shortcomings in VPNs become more apparent, organizations are searching for secure alternatives and Bastion Hosts have emerged at the forefront. From being a projection of a castle in ancient times to a part of the IT infrastructure of many organizations currently, the humble 'Bastions' are used where they are seen fit, and rightly so. The ease of configuring and deployment makes it popular.

Although Bastion Hosts have many use cases, they tend to remain independent of each other. Configuring a Bastion host for an authentication gateway and implementing it in an existing IT infrastructure differs greatly to file transfers. There is also an inherent reliance on SSH which can be targeted by attackers.

If only there was a platform that can present the above-mentioned use cases of a bastion host easily and securely, organizations can get broader use cases with tighter security into their servers!

7 Alternative Use Cases for a Bastion Host

## Introduction to Identity and Access Management

Identity and Access Management (IAM) is the branch of IT security that ensures that only authorized individuals in an organization have access to the resources they need to carry out their responsibilities. It forms a framework that helps govern and manage digital identities and data. 

This can be categorized into three key components:

1) Creation and management of Users, roles, and policies

2) Authentication of users based on the unique credentials they identify with

3) Authorizing the user based on the role they are given

Intuitively, IAM can be achieved by defining the identities of employees, their roles, and the tools they require to perform their respective tasks. The same can be explained through the use of authentication and authorization mechanisms, such as passwords, Multi-factor authentication (MFA), Single Sign-on (SSO), and role-based access controls (RBAC). 

IAM system simplifies the process of managing access to various applications, without requiring administrators to log in individually to each app. It also gives the organization a means to securely store identities and related data that can be used only when deemed relevant and necessary. The implementation of IAM can be done in many ways - on-premises, cloud-based, in a hybrid architecture, or through a third-party organization. The model that best suits any organization’s needs and architecture can be chosen.

## Five Pillars of IAM

To provide increased security and a seamless IAM experience to the employees, there are five major factors that need to be considered. These factors are also referred to as the five pillars of Identity and Access Management.

![image](https://cdn.sanity.io/images/yvzuzc4g/production/9a3969cd32f76a1696a4f9adf1be3b61c9a4f312-2918x1704.png)

### 1. User Authentication

Securing the organization’s sensitive data and restricting access to its resources is one of the most important tasks. In today’s era of digital theft, it is essential for an organization to protect its business from external threats that can impersonate users to gain access to the organization’s resources. Therefore, the first important pillar of IAM is to have a reliable user authentication process to offer a smooth and secure login and access to its employees only.

All IAM solutions have a variety of user authentication mechanisms beyond just ID-password-based authentication. These can be One-time passwords (OTP), Time-based One-time passwords (TOTP), Biometric authentication, certificate-based authentication, etc. Employees can authenticate via the IAM system through these authentication mechanisms.

### 2. Compliance and Privacy

The organization must focus on compliance and establishing relevant privacy policies. All IAM solutions must follow standards like [SOC 2](https://adaptive.live/blog/understanding-soc-2-types-principles-and-benefits), GDPR (General Data Protection Regulation - emphasizes an individual’s personal data and their right to data protection), HIPAA, COPPA, and other compliance updates to maintain the privacy rules and guidelines. 

Transparency must be prioritized in an organization. What data is stored, and how it is stored must be detailed and made known to the users. After the GDPR, many countries have come up with privacy compliance and data retention policies of their own that the organizations must adhere to. Therefore, governing privacy policies and the latest compliance standards is another important pillar for IAM. While it seems to be too sophisticated and resource intensive, the organizations also benefit from an increase in customer trust and acceptance to share data.  

### 3. High Availability and Scalability

For any IAM system, hundreds of individuals are expected to be identified and authenticated after verifying their digital identities and login credentials. While the mode of logging in might change between - remote and internal, the security posture remains the same. This authentication flexibility might not be part of certain IAM systems. 

IAMs should have high availability, with their security postures and preventative measures to also handle irregularities in the stream. Also, with the growing organization size, scaling the IAM system to reach all users is a necessary pillar. This scaling up and down can be made manually through vertical and horizontal scaling. The investment must be made to research the loads expected by the IT infrastructure of the organization. Failover mechanisms and data backups must be in place. 

Placing our focus on availability must not be an excuse to overlook the responsiveness and latency of the application(s) in question. Auto scaling can be employed, to save resources and money as well. 

### 4. Robust Encryption

In any organization, data is both in rest and in transit during the course of its usage in the infrastructure. Encryption is a strong tool that enforces the protection of confidential information and the employee’s digital identities. Data servers can be included in the architecture to be either on-site or cloud-based. 

Data in transit refers to the data being used to communicate with various infrastructure devices and servers. The data, irrespective of being in rest or transit, must be properly encrypted and stored in accordance with policies and compliance. 

The comprehensive protection that this pillar offers can be confused as being part of the compliance and privacy pillar. Encryption is but a tool to adhere to certain policies, so compliance and policy adherence can be thought of as an abstraction of data security.

### 5. Threat Analytics

By processing user activities, the organization can make better-informed decisions, which help improve revenue growth and retain customers, making analytics the most important pillar of IAM. Organizations see vast potential in the capabilities of IAM in the field of business analytics and data visualization.  

An IAM system must have the ability to record and generate reports on user logs, represent aggregate activities, and present them. The CISOs (Chief Information Security Officers) and other security experts of the organization may efficiently monitor the authentication and authorization data by utilizing these reports. 

Most IAM systems also visualize these data trends to make key decisions for the organizations which can be categorized into 3 analyzing techniques: batch, real-time and predictive analytics. IAM's real-time and predictive analysis tools can be used to quickly identify various risks, employee profiles, privileges, fraud detection, risk-based authentications, and other important information. It also helps in upcoming events and attacks, allowing the business to mitigate or completely avoid any harm.

## 6 Key Benefits of IAM

- **Centralized control**: In a scenario where the user is compromised, central control via IAM allows an organization to compartmentalize access and contain the breach to all the impacted services.

- **Improved security**: Enforcing least privilege access with IAM allows users to have the minimum level of access necessary to perform their tasks. The granular level of access reduces the risk of security breaches and unauthorized access to sensitive information.

- **Compliance**: Regulatory and governance requirements can be met by enforcing policies and centralizing access auditing via IAM to various services and resources.

- **Productivity**: System admin tasks of managing users, access, and authorization matrices can be maintained in an automated way with IAM.

- **Scalability**: As users and resources grow in an organization, IAM makes it easier to manage access, allowing you to scale your infrastructure as needed.

- **Flexibility**: IAM enables us to create, modify, and delete access policies as needed, allowing you to respond to changing business requirements and security needs.

## Challenges to IAM

Based on our research we categorize the challenges in Identity and Access Management as follows:

- **Complexity**: The complexity of IAM depends upon the permutations and combinations of roles, resources, users, and privileges with which users should interact. For instance, AWS IAM is powerful but complex—**its user guide is nearly 900 pages long.** It is next to impossible to understand what existing policies do; in certain scenarios, organizations buy tools to just manage the policies of IAM.

- **Integration**: Not all resources work seamlessly with all IAM systems. The granularity provided by resources often doesn’t match IAM roles and policies. These situations often require custom changes, thus extending implementation timelines from weeks to months to years.

- **User adoption**: if the users already had unrestricted access before the system, the IAM system can often create barriers within organizations. Also, many IAM systems do not have request-approval flows that can lead to access requests in the bureaucratic abyss.

- **Scalability**: As the number of users and resources grows within an organization, managing IAM policies and access controls becomes increasingly complex, which can lead to leaky authorization and vulnerability if not managed.

- **Security**: Ensuring the security of IAM systems and policies is crucial, as a breach in the IAM system could compromise the security of all resources.

- **Cost**: Implementing and maintaining IAM systems can be expensive, and organizations need to balance the costs with the benefits.

Identity and Access Management (IAM) explained

## What is SOC 2 compliance?

SOC 2 or formally Service Organization Control 2, is a security and privacy compliance standard that provides assurance to customers that a service provider has implemented appropriate controls to protect their data. The American Institute of CPAs (AICPA) produced SOC 2, a voluntary compliance standard for service organizations, which outlines how businesses should safeguard client data. 

Each organization's specific demands are taken into account while creating a SOC 2 report. Every organization has the ability to develop controls that adhere to one or more of SOC 2 trust principles depending on its unique business practices. These internal reports offer crucial details about how they handle their data to authorities, partners in business, and suppliers.

## Who needs SOC 2 Compliance?

SOC usually applies to most types of service organizations. The most common types include- 

- SaaS (Software as a service) companies that offer programs, apps, and websites
- Businesses that offer management, analytics, and business intelligence services
- Organizations that manage, support, or offer advice on accounting or financial procedures
- Organizations that offer client-facing services like customer service management
- Companies that provide managed IT and security services, including those that support SOC2

You might need to comply with SOC if your business fits any of the above descriptions. While the SOC primarily focuses on these service businesses, there are other regulatory rules that AICPA offers both inside and outside of the SOC framework that extends its protections to the supply chain and beyond.

### SOC Applicability to the Supply Chain

To address the demands of their own clients, service organizations collaborate with several vendors, suppliers, and other service providers. There are new dangers at every point of engagement since there are many players involved. Consequently, the AICPA has created a flexible, voluntary SOC system for the supply chain.

Companies belonging to the supply chains for service organizations may provide information about their own security procedure to them. Also, service organizations have the choice to include specific suppliers in their SOC reports. As a general rule, the more transparent a system is, the more secure it is.

The AICPA offers a wealth of useful materials to help service companies and their business partners understand the needs of all the stakeholders. 

## SOC 1 vs SOC 2 - What is the difference?

![Frame 18140679.png](https://cdn.sanity.io/images/yvzuzc4g/production/762ec3c2a1f424f43b4871feb176a2d0d23b6e47-2189x1342.jpg)

The main difference between SOC 1 and SOC 2 is the focus of the audit and the type of information that is covered in them. 

**SOC 1**: The purpose of a SOC1 audit is to review and report an organization’s internal controls which focus on its customer’s financial statements. It covers controls that process and secure customer information around business and IT processes. The resulting report is used by the customer’s management and external auditors.

**SOC 2**: The SOC2 report is focused on an organization's controls pertaining to the 5 trust principles- security, availability, processing integrity, confidentiality, and privacy. It provides assurance that the service organization has implemented appropriate controls to meet these trust principles and protect customer data. The report is intended for use by the service organization's management and prospective customers and stakeholders. 

To summarize, SOC 1 reports focus on financial controls, while SOC 2 reports focus on the 5 Trust Service Principles. It is recommended that organizations choose both types of reports if they need assurance on both financial reporting as well as information security.

There is also the third level of SOC called **SOC 3.** The SOC 3 reports are simplified versions of SOC 2 reports that cover many of the same principles but are intended for wide publication, such as on a company’s website. They facilitate communication of a company’s security to its stakeholders.

SOC 1 and SOC 2 produce more profound, more significant insights that companies can share with customers and stakeholders. SOC 3 reports are purely for public consumption and often cannot fulfill industry norms or requirements.

# Who can perform a SOC 2 Audit?

SOC 2 Audits can be carried out by either a Certified Public Accountant (CPA) or a certified technical expert belonging to an audit firm licensed by the AICPA.

The SOC 2 Audit provides the organization’s detailed internal controls report made in compliance with the 5 trust principles. It shows how well the organization safeguards customer data and assures them that the organization provides services in a secure and reliable way. SOC 2 reports are therefore intended to be made available for the customers and other stakeholders only.

SOC 2 is different from other compliance frameworks in their audit reports, as even though the internal controls are set in accordance with the 5 Trust Services Criteria (TSC), they may vary from organization to organization. Depending on the Trust Service Criteria, an organization can have different objectives to achieve and in turn finalize different controls for their SOC 2 compliance.

It's important to note that the SOC 2 audit reports are only a point-in-time assessment and do not provide ongoing assurance to the customer. The service organization is responsible for maintaining, monitoring, and updating its controls on a regular basis to reflect any changes done to its systems and operations.

## SOC 2 Trust Service Principles

![Frame 18140678.png](https://cdn.sanity.io/images/yvzuzc4g/production/f29810402ea5380ae85918b9094bc26e60b12d62-2189x1342.jpg)

SOC 2 has five trust service principles that organizations must meet in order to achieve compliance:

1. **Confidentiality**: The organization must protect the confidentiality of customer data and ensure that it is only used for authorized purposes. Some of the confidentiality control checks include:
    - Data classification and protection
    - Data privacy and protection of sensitive information
    - Encryption of data in transit and at rest
2. **Processing Integrity**: The organization must ensure that all transactions are processed accurately, completely, and in a timely manner. Some of the controls related to integrity include:
    - Data completeness and accuracy
    - System and application processing
    - Data backups and recovery
3. **Availability**: The organization must ensure that its systems and services are available and accessible to customers as promised. A few controls that ensure the availability of data include:
    - Disaster recovery plans and business continuity policies
    - Monitoring and maintaining systems and applications
    - Capacity planning
4. **Security**: The organization must have appropriate security measures in place to protect customer data which are related but not limited to:
    - Physical and environmental security of facilities
    - Identity and Access Management
    - Network security and data protection
    - Incident management and response
5. **Privacy**: The organization must respect the privacy rights of customers and properly handle and protect their personal information. Some of these controls might include:
    - Privacy policy and data protection framework
    - Data breach management and notification

## Soc 2 Type 1 vs Type 2

There are two types of SOC 2 reports - SOC 2 Type 1 and SOC 2 Type 2.

SOC 2 Type 1 report evaluates if the controls are being designed and implemented successfully in the organization's systems. The goal is to check if the internal controls are sufficient to safeguard customer data. SOC 2 Type 1 audit is done at a particular point in time and hence does not offer any proof of the controls' sustained operations.

SOC 2 Type 2 report evaluates the design, implementation as well as effectiveness of the organization’s internal controls. Type 2 report tests the internal controls thoroughly over 6 to 12 months time and reports the operating effectiveness of the internal controls.

In general, SOC 2 Type 2 reports are considered to be more comprehensive and provide a more robust assessment of the service organization's controls. Overall, Type 2 audits take longer to complete and are more expensive than Type 1 audits. Customers and stakeholders who wish to understand the amount of risk associated while using the service as well as the long-term efficiency of the service organization's controls frequently choose Type 2 reports.


## SOC 2 compliance checklist

Here is a checklist to prepare for your SOC 2 audit:
1. **Type 1 or Type 2 or both**: Decide whether you need Type 1 or Type 2 or Type 1  followed by Type 2
2. **Trust Services Criteria**: Identify which Trust Services Criteria are most valuable for your organization.
3. **Risk Assessment**: Do an internal Risk Assessment to understand your current posture?
4. **Gap Analysis**: Fill in the gaps identified during the Risk Assessment, where feasible.
5. **Readiness Assessment**: Hire an agency or use your compliance automation tool to see your readiness for a full SOC 2 audit.

## Importance and benefits of SOC 2 compliance

SOC 2 offers great benefits which include:

1. **Customer Assurance and Improved Reputation**: Compliance with SOC 2  assures customers that the service organization has implemented appropriate controls to protect the data and comply with relevant regulations. This helps build trust and credibility with customers and builds the organization’s reputation in the market.
2. **Overall security:** The SOC 2 audit process can help organizations find and address potential security and privacy risks, which can help improve the overall security and privacy policies of the organization.
3. **Compliance with regulations:** SOC 2 compliance can help organizations comply with information security and privacy policies, such as the GDPR and HIPAA.
4. **Informed decision-making:** Organizations that use third-party service providers can use SOC 2 reports to make informed decisions about their use of services.

Understanding SOC 2: Types, Principles and Benefits

## What is Credential Management?

Credential management refers to the process of creating, storing, and using digital credentials, such as passwords, user names, and security certificates, to authenticate and authorize users, devices, and/or systems. 

A Credential Management System is a solution that stores all the credentials centrally and gives access to the credentials to authorized users only. In growing organizations, it improves security and eases [Identity and Access Management](https://adaptive.live/blog/identity-and-access-management-iam-explained). 

The goal of credential management is to provide a secure and efficient way to manage access to protected resources while minimizing the risk of unauthorized access and data breaches. This typically involves the use of secure protocols, encryption, and multi-factor authentication to ensure the integrity and confidentiality of credentials and protected resources.

## Why is credential management important?

**It helps to protect sensitive information and resources from unauthorized access**
    
In today’s digital age, businesses rely heavily on technology and the internet to store, process, and transmit sensitive information, such as financial data, customer information, and confidential business plans. If this information were to fall into the wrong hands, it could have serious consequences for the business and its customers.
    
**Ensure compliance with various regulations such as HIPAA, PCI-DSS, SOC2, SOX, etc**
    
These regulations have strict requirements around access controls, passwords, and audit logging. Failure to comply with these can lead to fines and penalties, thereby negatively impacting the company’s reputation.
    
**It helps avoid secrets sprawl**
    
A situation where the secrets (API-tokens, certificates, credentials, etc.) end up in multiple places like plain-text, dev machines, encrypted DBs, or 3rd party services. This poses security risks in case any of the above are compromised. The secrets are hard to track, update, and/or delete from everywhere.
    
## Types of Credentials

Credentials are a way to identify and validate a user to grant them access to websites, databases, networks, etc. Credentials are categorized primarily into two types:

1. **Passwords** are a form of authentication used to verify the identity of a user or system. Used to protect sensitive information and resources, such as financial accounts, personal data, and confidential documents, from unauthorized access. Passwords are the most common type of credentials used for authentication.
2. **Secrets** are another type of credential used for authentication, typically in the form of a token or a key. They are used to grant access to resources without the need for a user to enter a password. Examples include:
 - API and other application keys/Credentials
 - SSH Keys, Private certificates for secure communication, transmitting and receiving of data (TLS, SSL, etc)
 - Biometric information

![Best Practices](https://cdn.sanity.io/images/yvzuzc4g/production/336aa74bf9c62a9edde314ddb3c6e184a5f74074-2189x1342.png)

## Password Management vs Secrets Management

People often get confused between password management and secrets management and often use them interchangeably. Let’s look at how they’re actually different.

### What is the difference between Password Management and Secrets Management?

Password management and Secrets management are both practices used to secure sensitive information, but they are slightly different in their focus and use cases.

**Password Management** refers to the process of managing and storing authentication information, such as usernames and passwords. 

The goal of Password management is to ensure that only authorized users have access to the information they need to do their jobs, while also making it easy for those users to access the information they need. 

This can include practices such as password rotation, multi-factor authentication, and centralized storage of credentials.

Some of the best password managers are Google Password Manager, MacPass, LastPass, NordPass, SafeInCloud, StrongPass, EnPass, DashLane, and 1Password.

**Secrets Management**, on the other hand, refers to the process of managing and storing sensitive information, such as encryption keys, API keys, and other information 
that needs to be kept secure. 

The goal of secrets management is to ensure that sensitive information is kept secure and that it is only accessible by authorized users and systems. 

This can include practices such as encryption, access control, and centralized storage of secrets.

Some of the best secrets services used for secrets management are Hashicorp vault, AKeyless, AWS Secrets Manager, GCP Key Management Service (KMS), Azure, and Doppler.

In short, Password Management deals with passwords for human-authentication whereas Secrets Management deals with secrets for human to service or service to service authentication.

Both of these practices are essential for keeping an organization’s sensitive information secure, but they may be implemented using different tools and technologies depending on the specific use case.

But how about a Password Manager that can be used for both ~~Credential~~ Password management as well as Secrets management? 1Password is one such example of a password management service that is working on providing both at the same time.

### **Can Password Management services compete with Secrets management?**

A password management service typically focuses on storing, generating, and retrieving passwords for the users and can be integrated with other applications to automate the process of logging in. However, a full-featured credential management service provides more comprehensive management of authentication and authorization for a wide range of resources, including but not limited to web applications, networks, databases, and APIs.

With password management services expanding into [enterprise secret management](https://1password.com/product/secrets/), it appears they want to handle the authentication processes of services too (like they do for humans right now) by being the proxy/interface between a secrets management service and user/services.

This requires the companies to deploy an additional service (like 1Password’s connect-server) in the K8s cluster or elsewhere, that will act as the authentication provider.

It is yet to be seen how this plays out over the years, but it definitely comes with its own benefits and shortcomings:

#### Benefits
- Better user experience as the password management service can handle the management and authentication of secrets for the user, simplifying the process.
- Increased security as the password management service can enforce policies and best practices for managing secrets.
- Reduced risk of human error as the password management service can automatically rotate and update secrets.
- Increased efficiency as the password management service can automate the process of granting access to secrets.
#### Shortcomings
- Vendor lock-in for access to Key Management Service (KMS).
- Lack of self-hosting options can be a concern for companies that want to keep their data in-house.
- Leads to dependence on external services provider which results in transitive [exposure to their cybersecurity weaknesses](https://www.techtarget.com/searchsecurity/news/252529329/LastPass-faces-mounting-criticism-over-recent-breach).

## Best practices for Credential Management

### Implement an organization-wide password manager
![Password Manager Benefits](https://cdn.sanity.io/images/yvzuzc4g/production/c553e04fa105ed136aad1ff1234ec73b8a9ed919-2918x1788.png)

Implementing an organization-wide password manager will help to make sure every employee follows the same standards for passwords. Password managers also ensure heightened security as they store all the different passwords and avail them to the user at their fingertips. A password manager can be used to implement the following guidelines:

1. **Enforce a password policy**
2. **Ensure strong/unique passwords:** Strong passwords are essential for protecting against cyber attacks. It is best practice to use passwords that are at least 8 characters long and include a combination of upper and lower case letters, numbers, and special characters. It is also important to use unique passwords for each account to prevent attackers from using the same password to gain access to multiple accounts.
3. **Replace/detect passwords from databases like [haveibeenpwned](https://haveibeenpwned.com/)**
4. **Enable two-factor authentication:** Two-factor authentication (2FA) adds an additional layer of security to login processes by requiring users to provide a second form of authentication in addition to their password. This can include using a security token, receiving a code via text message, or using a biometric factor such as a fingerprint or facial recognition.
**Remember to save backup keys to a 2factor device, to avoid a Single Point of Failure*
5. **Audit:** A business should be able to audit and capture - activity, date, and actor for all changes taking place in the password manager. 

### Consolidate Identity, Access, and Authorization

Bring all aspects of user authentication, authorization, and credential-lifecycle management under one roof. This has several benefits:
1. Centralized management makes it easier to monitor and control access to network resources, as all access attempts are channeled through a single point.
2. Encryption at rest ensures that user credentials are protected even if the system is compromised, as the data is stored in an encrypted format that can only be decrypted with the proper keys.
3. Access lists provide a more granular level of control over who has access to what resources, allowing the organization to specify exactly who can access what resources and when.
4. Audit capabilities make it easier to track and investigate any suspicious activity, as all access attempts are logged and can be reviewed later.
5. The ability to revoke access quickly and easily makes it easier to respond to security incidents, as access can be revoked as soon as an incident is detected.
6. Unique / Dynamic tokens can be generated for each user, providing an additional layer of security as tokens can be easily invalidated if compromised.

---

## The future of Credential Management

The future of credentials is rapidly evolving as technology advances and cyber threats become more sophisticated. With the advent of zero trust and just-in-time access, multi-factor authentication, continuous monitoring, and granular access controls will become the norm.

### **Zero trust / Just-in-time Access**

Zero Trust includes multi-factor authentication, continuous monitoring and analysis of network activity, and granular access controls based on user, device, and resource attributes. This can be achieved using technologies such as software-defined perimeter, network segmentation, and user and entity behavior analytics.

Just-in-time access (JIT) is an approach to user authentication and authorization that grants access to network resources only when it is needed and for the minimum amount of time necessary. This approach differs from traditional credential management services, which typically grant access to resources on a long-term basis, such as through the use of static, long-lived credentials.

Credential management will still play an important role, as it is responsible for creating, storing, and using digital credentials to authenticate and authorize users and devices. However, it will be more dynamic and will be integrated with other security solutions to enable more granular and more real-time access control decisions. We will see credentials management services move away from manually created passwords to dynamic, time-gated ( or privilege-gated ) secrets/passwords. Adopting zero trust and JIT will complement contemporary credential management services.

### **Passkeys / WebAuthn**

WebAuthn is a web API standard that enables web applications to authenticate users using a hardware security key, such as a USB dongle or a built-in biometric sensor on a device, instead of a password. 

Passkeys are based on WebAuthn and provide password-free login to apps and websites.
They are digital credentials that are kept on your devices, and biometrics are used to access them.

This improves security by making it much more difficult for attackers to steal users’ login credentials, as the hardware key provides a secure way to verify the user’s identity. Additionally, WebAuthn supports a wide range of authenticators, from those based on public key cryptography to those that use biometric data, such as fingerprints or facial recognition. Overall, WebAuthn is a secure and flexible way for web applications to authenticate users and is widely supported by modern web browsers and platforms.

 More and more password management services will adopt passkeys in the future.

### **Time to say goodbye to VPNs**

VPNs present security weaknesses by offering binary modal access to the network and its resources. They do not effectively implement policies such as least privilege, which safeguards credentials. Also, they usually do not have extensive auditing capabilities beyond logging connection times and their payloads.

Zero-trust gives segmented access to one or more resources as and when required. Zero-trust services have the ability to sniff traffic to resources (using special channels like bastion servers) and understand/log what changes or access is made to what resources.

Credential management services of the future, powered by Zero trust and Just in time access features, will make VPNs a thing of the past.


Credential Management explained: Best Practices and the Future


## What is an Authentication Protocol?

Authentication is the process of determining whether a user is who they claim to be. 

More formally, authentication protocols define the contents of the authentication data itself, the mode of its transfer, and the communication that must take place between two entities (server and client) in a network.  

No Authentication protocol is completely secure and yet each offers adequate security and advantages in specific contexts. We discuss several of these protocols and the context of their use.

## Application Layer Protocols

### Kerberos

The Kerberos protocol (1988, [spec](https://web.mit.edu/Kerberos/)) uses time-limited and encrypted tickets to validate clients and servers over an insecure network.  Once authenticated, the user can transparently access all resources on the network they are authorized to access.
![kerberos](https://cdn.sanity.io/images/yvzuzc4g/production/f5f1df3764759932af8a0c42d8f1f7d54c6ba75b-4118x2482.png)
#### When should you use Kerberos?

- **Environments with sensitive data:** Kerberos provides a high level of security, making it suitable for on-premise environments with sensitive data, such as financial institutions and healthcare organizations.

### **Lightweight Directory Access Protocol (LDAP)**

Even though LDAP (2006, [spec](https://www.rfc-editor.org/rfc/rfc4511)) is often clubbed into various authentication protocols, it is really a directory and access management protocol that defines how one should talk to a directory server. It works on TCP/IP. Most systems use LDAP to talk to a directory to retrieve user accounts, verify them, and access attributes associated with these accounts.
![ldap](https://cdn.sanity.io/images/yvzuzc4g/production/8ad1e4be97f5cbc899d6f4a9039ccbb521d07977-4118x2482.png)

#### When should you use LDAP?

- Situations where on-premise authentication is needed.
- Situations where organizations want to maintain their own directory to store and manage user information, such as passwords, email addresses, and other data, on their own servers.

### **Security Assertion Markup Language (SAML)**

SAML (2008, [spec](http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html)) is an XML-based framework for describing and exchanging assertions that applications working across security domain boundaries can trust. E.g. a typical assertion from an identity provider (IdP) would convey, “This user is John Doe, with the email address [john.doe@example.com](mailto:john.doe@acompany.com), and was authenticated using a password mechanism.” A service provider (SP) could choose to use this information, depending on its access policies, to grant John Doe web SSO access to local resources. 

![saml](https://cdn.sanity.io/images/yvzuzc4g/production/f710de62af3ad671be1bcf0fa1411e1595274b35-4118x2482.png)

#### When should you use SAML?
- **Situations where you do not want to create and maintain user information directories**
- **Situations where security as well as user-experience are important:** SAML provides increased security in addition to improving the user experience. Because the identity provider stores all login information, the service provider does not need to keep user credentials on their system. Additionally, the identity provider can devote time and resources to implementing multiple layers of security because they specialize in providing secure SAML authentication.

### **Central Authentication Service (CAS)**

Central Authentication Service (CAS) is a single sign-on protocol where the authentication process can only happen on the CAS server, so applications that authenticate with CAS never see the user’s credentials. 

#### When should you use CAS?

- **Situations where security is a priority.** Credentials are less likely to get compromised using CAS protocol as applications never see them
- **Situations where multi-tier authentication is required:** CAS uses a proxy address to authenticate users. A database server or mail server can be used as an intermediary to validate the identity of the user from the information it received from the application. Other identifying parameters or criteria can be defined on this trusted and safe proxy server, enabling a multi-tier authentication service.

### **OpenID**

OpenID ([spec](https://openid.net/specs/openid-authentication-1_1.html)) was created to solve SSO for non-enterprise end users. It allowed end users to specify URLs as their identifiers. e.g. An end user claiming [http://www.example.com](http://www.example.com) as their identifier, would include a link to their IdP in the HEAD section of the HTML document served by http://www.example.com. OpenId was never widely used but led to the evolution of OIDC.

#### When should you use OpenID?

- The authentication is offloaded to the OpenID provider, and their security systems can be leveraged. Anyone can become an OpenID Provider without requiring third-party registration/approval

### **OAuth**

While SAML and OpenID enabled end users (Resource Owners) to SSO for protected resources, there was still no mechanism to authorize applications to directly access users' resources without the end user's credentials. OAuth (2010, [RFC 5849](https://www.rfc-editor.org/rfc/rfc5849)) enabled this by verifying not only the end user's authorization to access the resource but also the identity of the application making the resource request. e.g. applications using Google’s API often rely on OAuth to act on behalf of the end user. 
![oauth](https://cdn.sanity.io/images/yvzuzc4g/production/fad90c247eceda0c8241401476699f3eab4d9d06-4118x2482.png)
#### When should you use OAuth?

- **Situations where user convenience is a priority:** OAuth provides a convenient and user-friendly way for users to grant access to their data, making it useful in situations where user convenience is a priority, such as in e-commerce applications.
- **Situations where users need to grant access to their data:** OAuth enables users to grant access to their data to third-party applications or services, without having to share their login credentials. This makes it useful in situations where users need to grant access to their data, such as when using a fitness tracker app that needs access to their health data.
- **Environments with multiple service providers:** OAuth allows users to grant access to their data to third-party service providers without sharing their login credentials. This makes it useful in environments with multiple service providers, such as social media networks.

## Link Layer Protocols
The protocols discussed so far are application layer protocols and the more frequently encountered. There are other lower layer protocols that are less frequently encountered because as end users we don’t have to deal with them directly.

### Password Authentication **Protocol (PAP)**

PAP (1992, [RFC 1334](https://datatracker.ietf.org/doc/html/rfc1334)) is an authentication protocol used between two directly linked nodes. It is used only at the initial link establishment phase where the client uses a two-way handshake to establish its identity to the server. In the handshake, an ID and password pair is sent to the server as plain text and the server matches the ID-password pair against a local copy/hash. 

#### When should you use PAP?

- **Situations where it is okay to transfer plain text credentials** for authentication because the link over which it travels is itself secure.
- **Where the plaintext password must be available at the remote host** either to simulate a login or to match it against stored copy/hash.

### Challenge-Handshake **Authentication Protocol (CHAP)**

CHAP (1992, [RFC 1334](https://datatracker.ietf.org/doc/html/rfc1334)) is another authentication protocol used between two directly linked nodes. It is used during the initial link setup phase and may be repeated later for re-verification. It uses a three-way handshake where the server sends a unique and unpredictable "challenge" message to the client.  The client responds with a value calculated using a "one-way hash" function.  The server checks the response against its own calculation of the expected hash value.  

#### When should you use CHAP?

- **Situations where the link is susceptible to eavesdropping.**

### **Extensible Authentication Protocol (EAP)**

EAP (1998, [RFC 2284](https://datatracker.ietf.org/doc/html/rfc2284)) is another authentication protocol used between two directly linked nodes. It is extensible in that it supports multiple authentication mechanisms including the use of another authentication server. The server sends a request to authenticate the client but unlike CHAP where the information exchange is fixed, a request in EAP specifies the type of information being requested e.g. Identity, OTP, MD5-challenge, etc. The client responds with the requested information which the server validates.

#### When should you use EAP?

- **Situations where the flexibility of choosing an authentication mechanism is required.**

### **Terminal Access Controller Access-Control System (TACACS)**

The original TACACS protocol (1984, [RFC 1492](https://www.rfc-editor.org/rfc/rfc1492)) defined how end users, who want to use a dial-up line, should authenticate to a TACACS server by sending a username and password. The criteria for authentication was left open for the TACACS authentication server which could use, in addition, other parameters such as time of day or other users already using the network. 

#### When should you use TACACS?

- **Situations where it is necessary to define a custom authentication algorithm.**

Authentication Protocols: Types and Uses

## What is an AWS Bastion Host?

A Bastion Host (or a jump server) is a dedicated computer used to access infrastructure resources and helps compartmentalize them. From a security perspective, a Bastion host is the only node in the network exposed for external access.

Remote access to databases and other servers is often required for administrative chores and troubleshooting. But exposing these servers for public access also exposes them to attacks. 

![Without Bastion](https://cdn.sanity.io/images/yvzuzc4g/production/18eaaee9426b08a98ab8589b28df09444e7847f5-2918x1788.png)

Organizations instead designate a hardened intermediary server (or jump server) that is the only one open for external ssh access. All the other business-critical infrastructure is accessed through this bastion host. Access policies and audit infrastructure are set up just on the bastion host instead on each and every DB and server.

![With Bastion](https://cdn.sanity.io/images/yvzuzc4g/production/8813b09c7ab67437e9a80d32e9b9eecf303e7ce0-2918x1788.png)

## Creating an AWS Bastion Host

The below steps show how to create a simple AWS Bastion Host (or jump server) for your infrastructure. Later we also outline additional considerations for a more sophisticated setup.

### **Create an EC2 instance**

- Create an EC2 instance to be used as a bastion host. This instance will NOT require high CPU/memory resources as it will not run any services except those required for its function as a bastion host.
    
![Launch an Instance](https://cdn.sanity.io/images/yvzuzc4g/production/6296ff550eb25fab0b7a445e9004da0144403194-1366x642.png)
    

### **Configure Security Groups**

- Security groups on AWS are used to allow inbound connections on specified ports from specified IPs. Create a security group to allow SSH access to the bastion host from 0.0.0.0/0 and associate this security group with the bastion host.
    
    ![Edit inbound rules for Bastion](https://cdn.sanity.io/images/yvzuzc4g/production/a9cc02a888da0012608d4d08a6f9fa0dbe443b2b-1366x642.png)
    
- Create another security group to allow SSH access only from the bastion host’s IP. Associate this security group with the rest of your infrastructure.
    
    ![Edit inbound rules for servers](https://cdn.sanity.io/images/yvzuzc4g/production/ee26b70fd11757939985ecae0bf21392a60b6129-1366x642.png)
    

### Verify the Setup

#### Connecting directly to the server/DB fails

```bash
$ ssh -i aws.pem admin@13.127.194.184
ssh: connect to host 13.127.194.184 port 22: Connection timed out
```

#### Connecting via Bastion host works

```bash
$ ssh -i aws.pem admin@65.1.126.16
Linux ip-172-31-25-53 4.19.0-21-cloud-amd64 #1 SMP Debian 4.19.249-2 (2022-06-30) x86_64
Last login: Tue Jan  3 00:52:15 2023 from 122.161.64.244
```

```bash
admin@ip-172-31-25-53:~$ ssh -i aws.pem admin@13.127.194.184
admin@ip-172-31-39-72:~$
```

The `-J` option can be used for connecting to the server in a single command.

### Additional Considerations

#### Elastic IP (or Static IP)

The Bastion host's public IP is likely to change on machine restart. When this is an issue, consider allocating an Elastic IP (or Static IP) to the Bastion host.

#### **Limiting Source IPs**

If there is a fixed set of IP addresses from which the bastion host will be accessed, allow only those in the inbound rules.

#### Audit

Openssh on Linux includes logs of successful and failed login attempts, typically in `/var/log/auth.log`:

```bash
Jan  4 04:54:55 ip-172-31-25-53 sshd[13693]: Accepted publickey for admin from 3.131.228.105 port 53574 ssh2: RSA SHA256:ac6wLNaNL7NpWhfJSSD+T3nHnNQQeXJkyBJKi4kO9Zo
Jan  4 04:54:55 ip-172-31-25-53 sshd[13693]: pam_unix(sshd:session): session opened for user admin by (uid=0)
Jan  4 04:54:55 ip-172-31-25-53 systemd-logind[523]: New session 42617 of user admin.
Jan  4 04:54:56 ip-172-31-25-53 sshd[13693]: pam_unix(sshd:session): session closed for user admin
Jan  4 04:54:56 ip-172-31-25-53 systemd-logind[523]: Session 42617 logged out. Waiting for processes to exit.
Jan  4 04:54:56 ip-172-31-25-53 systemd-logind[523]: Removed session 42617.
```
#### **Subnets**

For an additional layer of security, put the bastion host in a public subnet and the remaining infra in a private subnet. Choose **VPC and more** when creating a new VPC to configure the subnets:

![Create VPC](https://cdn.sanity.io/images/yvzuzc4g/production/0df36b53a23590ef64294d3165863c53d4b2b4b8-1366x642.png)

#### **AWS Reference Deployment**

[AWS’s Reference Deployment](https://aws.amazon.com/solutions/implementations/linux-bastion/) provides a reference implementation. 

#### **Create a Bastion with Terraform**

Terraform scripts for a similar setup are also available [here](https://github.com/adaptive-scale/terraform-aws-bastion).

## Challenges with Bastion Hosts

An AWS Bastion Host is a good start to securing infrastructure access for a company from external threats, but implementing it, especially for larger organization sizes has some major challenges that need to be considered: 

### High Availability

In rare situations, a single bastion host can also be a single point of failure for accessing the internal systems. If your infrastructure lives in multiple availability zones, consider creating one bastion host for each.

### Scaling

As your company infrastructure grows, each with its credentials and maintenance, the use of bastion hosts can become cumbersome.

### Key Management

Bastion hosts don’t solve the problem of key management, as whoever needs access to the one server also needs the keys to access the bastion host and the server itself.

## Alternatives to a Bastion Host

There are different alternatives to Bastion Hosts that can be implemented based on the company’s requirements and size to manage their infrastructure access and security - 

### VPN

A VPN or Virtual Private Network allows the client host to become part of the company’s internal infrastructure dynamically. This also means that once inside a VPN one has access to all the hosts in the internal network. It is [relatively harder to set up and use](https://todo.adaptive.live/i/79801931/no-fear-when-vpn-is-here).

### VPN + Bastion Host

The combination of VPN and Bastion Host provides more security by addressing their limitations when either is used in isolation. The Bastion host limits access to infra within the VPN. And the VPN limits access to the Bastion host on the public internet. While more robust, it may be overkill for an organization with few infrastructure resources.

### SOCKS Proxy
A SOCKS Proxy can also be used to access internal applications behind a firewall that allows SSH connections only. e.g. the following ssh command starts a proxy on port 9999 on the local host.

```bash
$ ssh -i~/.ssh/aws.pem -D9999 admin@65.1.126.16
```

Remote applications behind the firewall can then be securely accessed by specifying the proxy to use e.g. the following accesses the remote application running on port 8888 via the proxy started above:
```bash
$ all_proxy="socks5://127.0.0.1:9999" curl 127.0.0.1:8888
<!DOCTYPE html>
<html>
<head>
...

```
## Conclusion

Bastion hosts are a way to provide a low-cost layer of security for a company’s infrastructure. They don’t necessarily solve all of the access management issues, but can be a good starting point for a company to secure its infrastructure access, only necessitating replacement with a more comprehensive solution when your company grows.

## Further Reading

1. The manual page for `ssh(1)` - OpenSSH remote login client
2. [AWS EC2 documentation](https://docs.aws.amazon.com/ec2/index.html)
3. [Sharing infrastructure access with developers](https://todo.adaptive.live/p/sharing-infrastructure-access-with#%C2%A7no-fear-when-vpn-is-here)
