Skip to content
/ iam-demo Public

Demo code to explain how GRC, cybersecurity, and infrastructure automation can benefit from HR-Driven Identity Lifecycle and other IAM practices.

License

Apache-2.0, CC-BY-4.0 licenses found

Licenses found

Apache-2.0
LICENSE-CODE
CC-BY-4.0
LICENSE-DOCS
2 stars 0 forks Branches Tags Activity
Star
Notifications You must be signed in to change notification settings

sinetris/iam-demo

BranchesTags

Repository files navigation

IAM Infrastructure Prototype

Code for a fictional startup to explain how governance, risk management, and compliance (GRC), cybersecurity, and infrastructure automation can benefit from the use of HR-Driven Identity Lifecycle and other Identity and Access Management practices.

📝 Notice

You can see screenshots of some of the applications that will be provisioned with the current setup.

This project is ambitious and constantly evolving.

In the To Do document you can find what has been implemented and what is planned.

📜 Introduction

Stakeholders

The implementation of a proper IAM infrastructure requires the involvement of people from different teams and departments. Underestimating the need to involve all stakeholders at an early stage will lead to delays, waste of money and resources, and poor adoption.

The following is an incomplete list of candidate stakeholders:

  • Human Resources (HR)
    • People operations
    • Talent acquisition
    • Talent management
    • Diversity, Equity, and Inclusion (DEI)
  • Governance, Risk management and Compliance (GRC)
    • Information Security (especially the CISO)
    • Data Protection Officer
    • Compliance Officers
    • Risk Management
    • Internal Auditors
    • Legal team
    • Financial risk
  • Information Technology
    • CTO
    • Software Architects
    • Cyber Security
    • Site Reliability Engineering (SRE)
    • Platform
    • Business Application Owners
    • Engineering Managers

Workforce IAM

HR-Driven Identity Lifecycle

The HR department is the one that knows who is joining, who is leaving, who is moving to another job within the company, who is on vacation, sick leave, parental leave, etc. Their system should expose for each employee at least the name that should be used for them within the company (might be different from their legal name, which is only required by HR to sign contracts), the start and end dates (if applicable) of the contract, department, role, line manager, and absences.

Their database should be the source of truth for identities in the workforce. Other sources of truth can exist, but there must be a good reason for the exception. Furthermore, for such sources there needs to be an owner and at least one deputy responsible for the identities, and the identities need to be marked as “untrusted” and have a label with the source to help the Information Security team evaluate any access requests to internal systems.

Application Lifecycle Management (ALM) connected with the Asset Catalog

It is not possible to automate access to applications without knowing whether the application is in review, ready to be used or about to be decommissioned, who the Asset Owner is, what roles can be assigned to users, etc.

All applications and services must reside in an Asset Catalog, be labeled with the appropriate status and Information Assurance (IA) levels, and have assigned Asset Owners (and deputies), Application Administrators, and Infrastructure Administrators.

When selecting new applications and services, ensure that new systems have an appropriate interface for automated provisioning, preferring systems with SAML, SCIM, OpenID Connect, OAuth or at least appropriate API endpoints (or even better a supported connector for your IGA. See Evolveum Identity Connectors and Resources as an example).

Automated Provisioning

The HR department can provide us with some information about employees, but it is up to the Line Manager, with the help of the Asset Owners (and the Information Security team when in doubt), to determine which roles to assign them for day-to-day work (and it is preferable to use Profiles that aggregate access, e.g., a person working on a project will need access to the relevant chat channels, project emails, related services, etc.).

All access and communication channels necessary for people's daily work should be granted according to their profiles during on-boarding, based on their employment relationship, location, sub-company, department, their role in the teams, projects to which they are assigned, etc.

The exclusive use of RBAC to grant people access to services and applications will lead to a proliferation of roles that will quickly become unmanageable. My advice is to use a Policy-Based approach in a Zero Trust architecture.

All administrative access must be granted using short just-in-time credentials that needs approval. The approval process can be automated for exceptional cases using policies (e.g., an on-call engineer needs to work on a service they are assigned to during an incident).

Procedure and Processes

Many procedures and processes will benefit from a well-built IAM infrastructure.

These include, but are not limited to:

  • Business Continuity
  • Disaster Recovery
  • Internal Audit

🐣 Getting started

This project will create and provision 3 instances:

Warning

To keep the code as clean as possible, for the time being, this project is not designed to be backward compatible.

Instances are expected to be destroyed and recreated as new code may rename, remove, or modify resources in ways that could break previous deployments.

⚙️ Setup

Dependencies

Run

./project-management -a

💻 Linux desktop Instance

Connect using Remote Desktop

Use any RDP client, such as Windows App (formerly known as Microsoft Remote Desktop) or FreeRDP, to connect to the linux-desktop instance.

  • user: ubuntu
  • password: ubuntu

The IP Address is the first entry from ipv4 when running the following command:

./platform/project-script-generator/generated/instances-status.sh linux-desktop

Test self-signed certificates

The ansible scripts should have installed the self-signed root certificate inside the linux-desktop instance.

To test that the services are using the proper DNS and certificates, open a terminal in linux-desktop and type:

~/bin/check-instance-config.sh

The result should be similar to the OpenSSL Checks screenshot.

Complete Setup

Note: required to run only once

Configure environment variables and shell completion

Open a terminal and type:

# Configure iam-demo-tech k8s cluster as default
echo 'export KUBECONFIG=~/.kube/config-iam-demo-tech' | sudo tee --append /etc/bash.bashrc
# Add kubectl completion
kubectl completion bash | sudo tee /etc/bash_completion.d/kubectl
# Add kustomize completion
kustomize completion bash | sudo tee /etc/bash_completion.d/kustomize
# Add helm completion
helm completion bash | sudo tee /etc/bash_completion.d/helm
# Open a new shell tab or start a new shell to apply the changes
exec $SHELL
Configure Forgejo ssh keys

Open a terminal to generate the ssh keys.

ssh-keygen -t ed25519 -C "[email protected]"

Open a Forgejo in a browser and login using the credentials from Connect using linux-desktop browser.

Open a terminal and copy your public ssh key in the clipboard.

cat ~/.ssh/id_ed25519.pub | tee >(xclip -selection clipboard); echo ''

Open Manage SSH Keys in Forgejo in a browser and paste the public key.

🧑‍💻 Access Kubernetes cluster

Connecting from the console

Access ansible-controller shell using:

./platform/project-script-generator/generated/instance-shell.sh ansible-controller

or connect to linux-desktop using Remote Desktop and open a terminal.

You can also access linux-desktop shell using:

./platform/project-script-generator/generated/instance-shell.sh linux-desktop

To check the Kubernetes configuration, type:

kubectl config view

The output should be like the following:

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://iam-control-plane.iam-demo.test:6443
  name: default
contexts:
- context:
    cluster: default
    user: default
  name: default
current-context: default
kind: Config
preferences: {}
users:
- name: default
  user:
    client-certificate-data: DATA+OMITTED
    client-key-data: DATA+OMITTED

The kubernetes folder is mounted inside the ansible-controller under /kubernetes.

Connect using linux-desktop browser

Connect to linux-desktop using Remote Desktop.

Open Firefox inside the instance, and use the following URLs:

Note: You can also find them in the Firefox Bookmarks Toolbar under "Managed bookmarks".

To access Traefik or Kubernetes dashboards, follow the instructions in the respective subsections.

Traefik Dashboard

Open a terminal and start port forwarding using:

KUBECONFIG=~/.kube/config-iam-demo-tech
kubectl port-forward \
  --namespace kube-system \
  $(kubectl get pods \
    --namespace kube-system \
    --selector "app.kubernetes.io/name=traefik" \
    --output=name) \
  9000:9000

Open http://127.0.0.1:9000/dashboard/ in a browser.

Kubernetes Dashboard

Generate a token, print it and copy it to the clipboard:

kubectl -n kubernetes-dashboard create token admin-user | tee >(xclip -selection clipboard); echo ''

Start the proxy:

kubectl -n kubernetes-dashboard port-forward svc/kubernetes-dashboard-kong-proxy 8443:443

Access the kubernetes-dashboard in a web browser opening:

https://localhost:8443/

🧑‍🔧 Troubleshooting

🔧 Development

See development documentation.

🔖 Resources

Here are some useful links on topics that I consider relevant.

It’s a long and incomplete list.

IAM, IGA, CIAM, and Zero Trust architecture

Regarding IAM, IGA, CIAM, and Zero Trust architecture, KuppingerCole is a reliable source for an introduction to these topics:

The Evolveum website also contains a lot of good IAM introductory concepts:

Accessibility Directives and Guidelines

  • European Commission - Web Accessibility: Overview of the European Commission Web Accessibility Directive
  • EN 301 549: Accessibility requirements for ICT products and services
  • WAI: W3C Web Accessibility Initiative
    • WCAG: Web Content Accessibility Guidelines
    • ARIA: Accessible Rich Internet Applications suite of web standards
    • ACT: Accessibility Conformance Testing
    • EARL: Evaluation and Report Language
    • policies: Web Accessibility Laws & Policies

Compliance As Code

  • SCAP: Security Content Automation Protocol
  • OpenSCAP: open source security compliance toolkit

    NIST certified for SCAP 1.2

  • ComplianceAsCode: The ComplianceAsCode project

    Previously known as SCAP Security Guide (SSG)

  • OSCAL: Open Security Controls Assessment Language
  • Trestle: An opinionated platform to manage compliance as code using NIST's OSCAL standard
  • OPA: Open Policy Agent

    Declarative Policies - Context-aware, Expressive, Fast, Portable

  • OPAL: Open Policy Administration Layer

Frameworks and Regulations

Standard Notations

  • BPMN: Business Process Model and Notation
  • DMN: Decision Model and Notation

📄 Licenses

About

Demo code to explain how GRC, cybersecurity, and infrastructure automation can benefit from HR-Driven Identity Lifecycle and other IAM practices.

Resources

Readme

License

Apache-2.0, CC-BY-4.0 licenses found

Licenses found

Apache-2.0
LICENSE-CODE
CC-BY-4.0
LICENSE-DOCS
Activity

Stars

2 stars

Watchers

1 watching

Forks

0 forks
Report repository

Releases

No releases published

Packages

No packages published

Languages