Project Portfolio

Problem

Provide a hardened file transfer service with least-privilege access and predictable networking for partners and internal users.

Solution

• Terraform modules for VPC, subnets, security groups, and IAM permissions
• SFTP-only access with restricted users and locked-down inbound rules
• Logging/monitoring hooks for auditability and operational troubleshooting

Impact

• Repeatable, version-controlled infrastructure with consistent deployments
• Reduced manual configuration drift and improved security posture

Tech Stack

AWS (VPC, EC2, IAM, S3), Terraform, Bash

Production Thinking

• Least-privilege IAM and security groups for narrow ingress
• Structured logging and audit-friendly patterns for transfers
• IaC supports rollback and reduces configuration drift

Problem

Enable secure remote access without exposing internal networks, while keeping operations simple for support workflows.

Solution

• Infrastructure-as-code for compute, networking, and firewall rules
• Hardened inbound access patterns and least-privilege security groups
• Automated bootstrap to reduce manual setup steps and mistakes

Impact

• More reliable remote support flow with repeatable deployments
• Lower operational overhead through automation and standardization

Tech Stack

AWS (EC2, VPC, IAM), Terraform

Production Thinking

• Minimal exposure surface via security groups and explicit ports
• Automation reduces manual build steps and inconsistency
• Design supports teardown and rebuild for maintenance windows

Problem

Reduce manual admin work and errors when onboarding/offboarding users who need group-based access.

Solution

• Event-driven Lambda workflow to apply membership rules consistently
• API-based updates against Google Admin / Directory services
• Guardrails for validation and safe retries to avoid partial updates

Impact

• Faster provisioning with fewer helpdesk requests
• More consistent access control driven by automation

Tech Stack

AWS Lambda, Python, Google Admin SDK / Directory API, IAM

Production Thinking

• Validation and safe retries to avoid partial membership updates
• Operational logs for tracing API outcomes
• Scoped credentials and least-privilege service roles

Problem

Ensure users land in the correct Organizational Unit so the right policies, apps, and settings apply automatically.

Solution

• Serverless workflow to move users between OUs based on onboarding signals
• API-driven changes with validation for edge cases and mismatched inputs
• Operational visibility via structured logs for troubleshooting

Impact

• Consistent policy application and fewer manual corrections
• Improved onboarding speed and reduced admin burden

Tech Stack

AWS Lambda, Python, Google Workspace APIs, IAM

Production Thinking

• Input validation for mismatched or incomplete user records
• Structured logging for troubleshooting failed API calls
• Idempotent-style handling where possible to avoid duplicate moves

Problem

Remove Cisco components safely and consistently without leaving devices in a broken or partially removed state.

Solution

• Step Functions state machine orchestrating checks, removal, and verification
• Idempotent steps with retries and clear failure states for operations
• Separation of concerns: workflow orchestration vs per-step execution

Impact

• More predictable removals with fewer escalations and rework
• Clear audit trail of what ran and where failures occurred

Tech Stack

AWS Step Functions, Lambda, IAM, CloudWatch

Production Thinking

• Retries and idempotent steps to handle transient failures
• Clear state machine visibility for audits and incident review
• Separation between orchestration and per-step execution for maintainability

Problem

Deploy a private file collaboration platform with secure access patterns and reproducible infrastructure.

Solution

• Terraform for networking, compute, and baseline hardening
• Secure ingress/egress controls and environment separation practices
• Repeatable provisioning to support upgrades and recovery scenarios

Impact

• Consistent deployments and easier troubleshooting/rollbacks
• Improved resilience through standard infrastructure patterns

Tech Stack

AWS (VPC, EC2, S3, IAM), Terraform

Production Thinking

• Network segmentation and controlled ingress for collaboration workloads
• IaC supports cost-aware sizing and environment parity
• Operational focus on backup and recovery assumptions documented in code

Problem

Reduce onboarding lead time by converting structured Jira requests into consistent account provisioning actions.

Solution

• Jira-driven workflow that validates ticket fields before executing changes
• API Gateway + Lambda to apply provisioning steps in an auditable way
• Clear error states and notifications when prerequisites are missing

Impact

• Faster onboarding and fewer manual steps for IT operations
• More consistent outcomes with reduced human error

Tech Stack

AWS API Gateway, AWS Lambda, Python, Microsoft Graph / M365, Jira REST API, IAM

Production Thinking

• Ticket validation gates before any tenant changes
• Explicit error paths and notifications when prerequisites fail
• IAM-scoped roles for API integrations; logging for traceability

Problem

Eliminate the manual step of creating Amazon Connect accounts for Patient Care staff during onboarding, reducing provisioning lag and admin overhead.

Solution

• API Gateway receives Jira automation webhook on onboarding ticket transition
• Lambda validates the secret, filters for Patient Care department, and assumes a cross-account IAM role to create the Connect user
• Result (created or failed) posted as an internal Jira comment for a full audit trail

Impact

• Zero manual Connect provisioning steps for Patient Care onboarding
• Audit trail via Jira ticket comments confirming account creation per user

Tech Stack

AWS Lambda, Amazon Connect, AWS STS, AWS API Gateway, Python, Jira REST API

Production Thinking

• Webhook secret validation gates every request before any AWS action is taken
• Department filter (Patient Care only) prevents accidental provisioning from unrelated tickets
• Cross-account STS role assumption isolates Connect credentials from the Lambda execution role

Problem

Eliminate the manual, time-sensitive step of revoking Duo MFA access when an employee offboards, reducing the window of risk and admin overhead.

Solution

• API Gateway webhook receives Jira automation triggers on offboarding ticket transitions
• Lambda validates the request, calls the Duo Admin API to delete the user, and handles contractor bypasses
• Outcome (deleted, not found, or failed) posted as an internal Jira comment for a full audit trail

Impact

• Zero manual steps for Duo MFA revocation during offboarding
• Audit trail via Jira ticket comments showing deletion status per user

Tech Stack

AWS Lambda, AWS API Gateway, Python 3.12, Duo Admin API, Jira REST API, AWS SAM / CloudFormation

Production Thinking

• Webhook secret validation on every request prevents unauthorized invocations
• External contractor accounts bypass deletion with an explicit Jira comment for traceability
• Failure states post back to the Jira ticket so gaps never go unnoticed

Problem

Eliminate manual IT asset registration when hardware arrives from Softcat, preventing inventory lag and data-entry errors in Snipe-IT.

Solution

• FetchOrders Lambda queries Softcat's GraphQL API daily for invoiced orders and stages line items in S3
• PushToSnipe Lambda reads staged data, extracts chip type via regex, fuzzy-matches Snipe-IT models, and creates assets with cost, location, and supplier metadata
• PO number patterns automatically map orders to physical office locations

Impact

• Assets appear in Snipe-IT automatically on invoice, eliminating manual data entry
• Full order metadata (cost, supplier, invoice ID) captured for financial and audit tracking

Tech Stack

AWS Lambda, AWS S3, AWS SSM Parameter Store, Python 3.12, Softcat eCat GraphQL API, Snipe-IT API, AWS SAM / CloudFormation

Production Thinking

• State tracking in S3 makes the pipeline idempotent — invoiced orders are never double-processed
• Fuzzy string matching (SequenceMatcher + chip regex) handles minor title variations in Softcat order data
• Separated fetch and push Lambdas allow each phase to run, retry, or be debugged independently

Problem

Help users find answers quickly without repeatedly paging engineers for common support questions.

Solution

• Slack bot interface with structured prompts and response formatting
• Retrieval-augmented generation to ground answers in internal docs/sources
• Fallback messaging when confidence is low or sources are missing

Impact

• Reduced repeat questions and improved self-service support
• Faster time-to-answer with better user experience in Slack

Tech Stack

Python, Flask, Slack API, RAG / embeddings pipeline

Production Thinking

• Low-confidence responses avoid presenting guesses as facts
• Designed for maintainable prompt and retrieval updates
• Suitable for rate limiting and basic operational logging around requests

Problem

Website deployments depended on Jenkins, while validation and release visibility were moving to GitHub. This split ownership made troubleshooting, auditing, and maintenance slower.

Solution

• Implemented GitHub Actions validate and deploy workflows for this repository.
• Moved deploy operations to a self-hosted runner running in an LXC Debian container.
• Configured environment-scoped secrets for SSH key, host/path, and Discord webhook.
• Added deploy parity steps: validation checks, SSH sync, Nginx restart, and status notifications.

Impact

• CI/CD is fully running on GitHub Actions with successful production deployments.
• Jenkins is retained only as a commented fallback reference and is no longer the active path.
• Faster release feedback with clear run history and logs in one platform.

Tech Stack

GitHub Actions, self-hosted runner, PHP site deploy over SSH, environment-scoped secrets.

Production Thinking

• Secrets scoped to the deploy environment; no credentials in the workflow YAML.
• Deploy logs and run history centralized in GitHub for auditing and rollbacks.

Current workflow map

Validate: pull requests to main + manual runs.
Deploy: pushes to main + manual runs, with environment secrets.

Flow

Jira Automation → API Gateway (HTTP API) → VPC Link → internal ALB → EC2 Flask app

The EC2 app

• Receives a POST request
• Validates a shared secret
• Validates and normalizes the JSON payload
• Creates or disables a Pritunl user depending on the endpoint
• Sends credentials via SES for onboarding
• Writes a Jira internal comment
• Returns a JSON response

Onboarding path (manually validated)

Create the user, download the Pritunl profile ZIP, extract the limited .ovpn profile, email it through SES, delete the downloaded archive, and add a Jira internal comment — aligned with the repo’s expected behavior.

Fetches live user data by email from Snipe-IT and returns deployed assets (status label ID 5), accessories assigned to that user, and optionally posts a Jira internal comment when issue_key is provided.

Environment variables

• SNIPEIT_BASE_URL — e.g. https://snipeit.example.com
• SNIPEIT_API_TOKEN — Snipe-IT API token
• EXPECTED_SECRET — shared secret for API requests
• JIRA_URL — e.g. https://your-domain.atlassian.net
• JIRA_EMAIL — Jira API user email
• JIRA_API_TOKEN — Jira API token

Local usage

uv run hello.py "[email protected]"

AWS Lambda

• Handler: snipeit_api.lambda_handler
• Query (required): email
• Query (optional): issue_key
• Secret: query/body secret or header x-shared-secret
• SAM: template.yaml

Example event

{
  "queryStringParameters": {
    "email": "[email protected]",
    "issue_key": "IT-12345",
    "secret": "your-shared-secret"
  }
}

Example response

{
  "email": "[email protected]",
  "deployed_assets_count": 2,
  "deployed_assets": [
    {
      "status_label": { "id": 5, "name": "Deployed" },
      "name": "Mac mini (2018)",
      "serial": "C07XP1LHJYVW",
      "book_value": "0.00"
    },
    {
      "status_label": { "id": 5, "name": "Deployed" },
      "name": "MacBook Pro 14 - M4 Pro",
      "serial": "HK1FPW42GM",
      "book_value": "917.92"
    }
  ],
  "accessories_count": 2,
  "accessories": [
    { "name": "Magic Mouse A1657" },
    { "name": "Magic Keyboard MK2A3B/A" }
  ],
  "has_accessories": true,
  "jira_comment_added": true,
  "jira_issue_key": "IT-12345"
}

Deploy with SAM

sam build
sam deploy --guided

When prompted (or use --parameter-overrides), set: SnipeBaseUrl, SnipeApiToken, ExpectedSecret, JiraUrl, JiraEmail, JiraApiToken.

sam deploy --stack-name snipeit-user-search \
  --capabilities CAPABILITY_IAM \
  --parameter-overrides \
  SnipeBaseUrl=https://snipeit.example.com \
  SnipeApiToken=YOUR_TOKEN \
  ExpectedSecret=YOUR_SHARED_SECRET \
  JiraUrl=https://your-domain.atlassian.net \
  [email protected] \
  JiraApiToken=YOUR_JIRA_TOKEN

Source and supporting files for a serverless app that connects Jira webhooks to Snipe-IT user creation. The Lambda handles POSTs from Jira, validates them, and creates users in Snipe-IT when they do not already exist, with internal comments back on the Jira issue.

Application overview

The Lambda (app.lambda_handler) processes POST requests from Jira webhooks:

• Validation — X-Webhook-Secret header must match the EXPECTED_SECRET environment variable.
• Data extraction — Parses the Jira payload for user details (issue key, display name, email).
• Snipe-IT integration — If the user does not exist in Snipe-IT, creates a new user with a generated password and assigns them to group 6.
• Jira feedback — Posts internal comments to the Jira issue with success or failure.

Environment variables

• EXPECTED_SECRET — Secret for webhook validation.
• SNIPEIT_API_KEY — Bearer token for the Snipe-IT API.
• SNIPEIT_BASE_URL — Snipe-IT base URL (e.g. https://snipeit.example.com/api/v1).
• JIRA_URL — Jira instance URL (e.g. https://your-company.atlassian.net).
• JIRA_EMAIL — Email for Jira authentication.
• JIRA_API_TOKEN — API token for Jira authentication.

Automates creating Microsoft 365 (Azure AD) user accounts from open Jira Service Desk onboarding tickets, and posts credentials as internal comments on the same issues.

Features

• Fetches open onboarding tickets from Jira Service Desk.
• Automatically creates Microsoft 365 user accounts for Clinical department tickets.
• Generates strong random passwords for new accounts.
• Posts account credentials as internal comments on the Jira ticket.

Requirements

• Python 3.7+
• Microsoft 365 tenant with API access
• Jira Service Desk with API access
• Python packages (from requirements.txt): requests, python-dotenv

Setup

Clone the repository and install dependencies:

pip install -r requirements.txt

Create a .env file in the project directory with:

TENANT_ID=your-azure-tenant-id
CLIENT_ID=your-azure-client-id
CLIENT_SECRET=your-azure-client-secret

JIRA_URL=https://your-domain.atlassian.net
[email protected]
JIRA_API_TOKEN=your-jira-api-token

Usage

python JiraMSAccountCreation.py

The script fetches open onboarding tickets from Jira, creates a Microsoft 365 user for each Clinical ticket, and posts the username and password as an internal comment on the ticket.

Security

• Passwords are generated securely and only posted as internal comments visible to the Service Desk team.
• Never commit your .env file or credentials to version control.

Files

• JiraMSAccountCreation.py — main automation script.
• requirements.txt — Python dependencies.

Serverless automation that provisions Amazon Connect users for Patient Care staff directly from Jira onboarding tickets, eliminating manual account creation and posting the result back to the ticket.

Flow

Jira Automation rule → POST webhook → API Gateway → Lambda → STS assume role → Amazon Connect + Jira internal comment

Application overview

• Webhook validation — X-Webhook-Secret header checked against EXPECTED_SECRET; returns 403 on mismatch.
• Department filter — Only Patient Care tickets proceed; all others return 200 and are silently skipped.
• Cross-account access — Lambda assumes a dedicated IAM role in the Connect AWS account via STS, keeping credentials isolated from the execution role.
• Connect provisioning — Creates user with soft phone config, assigned routing and security profiles, using the employee email as username.
• Jira feedback — Posts an internal comment (Service Desk Team visibility) confirming creation or surfacing failures for manual follow-up.

Webhook payload

{
  "issueKey": "IT-456",
  "displayName": "Onboarding: Jane Smith",
  "email": "[email protected]",
  "department": "Patient Care"
}

Environment variables

• EXPECTED_SECRET — Shared secret for webhook validation.
• INSTANCE_ID — Amazon Connect instance ID.
• ROUTING_PROFILE_ID — Routing profile for new users.
• SECURITY_PROFILE_IDS — JSON array of security profile IDs.
• JIRA_URL, JIRA_EMAIL, JIRA_API_TOKEN — Jira API credentials for internal comments.

Production thinking

• STS role assumption scopes Connect access to a separate AWS account, limiting blast radius.
• Department filtering prevents tickets from unrelated teams from triggering provisioning.
• Failure path posts back to Jira so gaps are visible without silent drops.

Serverless app that listens for Jira offboarding webhooks and removes the departing employee from Duo Security, eliminating a manual, time-sensitive step in the offboarding process.

Flow

Jira Automation rule → POST webhook → API Gateway (/jira/offboarding) → Lambda → Duo Admin API + Jira internal comment

Application overview

• Webhook validation — X-Webhook-Secret header checked against EXPECTED_SECRET; returns 403 on mismatch.
• Payload parsing — Extracts issueKey and email from the JSON body; displayName is optional.
• Contractor bypass — @external.domain.com addresses skip Duo deletion but still receive a Jira comment for traceability.
• Duo deletion — Looks up the user via the Duo Admin API (tries original case and lowercase), then deletes by user ID. Handles three outcomes: deleted, not found, or failed.
• Jira feedback — Posts an internal comment restricted to the Service Desk Team role with the deletion outcome.

Webhook payload

{
  "issueKey": "HR-123",
  "email": "[email protected]",
  "displayName": "Offboarding: John Doe"
}

Environment variables

• EXPECTED_SECRET — Shared secret for webhook validation.
• DUO_INTEGRATION_KEY — Duo Admin API integration key.
• DUO_SECRET_KEY — Duo Admin API secret key.
• DUO_API_HOST — Duo API host (e.g. api-XXXXXXXX.duosecurity.com).
• JIRA_URL — Jira instance URL.
• JIRA_EMAIL — Jira API user email.
• JIRA_API_TOKEN — Jira API token.

Deploy with SAM

sam build
sam deploy --guided

All sensitive parameters are marked NoEcho in CloudFormation. The stack outputs OffboardingWebhookUrl — the POST URL to configure in Jira Automation.

Multi-module HR automation platform built on AWS Lambda and API Gateway. Ingests HiBob lifecycle webhooks and orchestrates employee workflows across seven integrated systems.

Flow

HiBob lifecycle event → API Gateway → Lambda → enrich via HiBob API → fan out to Jira / Slack / JAMF / Confluence / Totara LMS

Key workflows

• Onboarding — Creates Jira tickets and tasks for IT setup, equipment delivery, account creation, and Totara LMS enrollment.
• Offboarding / Leaver — Lambda filters “Leaver Workflow” tasks, enriches with termination data, and forwards to Jira to trigger IT asset recovery and access revocation.
• Parental leave — Detects parental leave workflow tasks and updates JAMF device extension attributes accordingly.
• Totara LMS export — Scheduled job fetches all HiBob profiles and transforms them into four CSV files (users, job assignments, orgs, positions) for Totara SFTP import.

Integrations

• HiBob REST API v1 & v2 — employee data and task webhooks
• Jira REST API v3 + Jira Automation webhooks — ticket and task creation
• Slack API — lifecycle event notifications
• Confluence REST API — knowledge base sync
• JAMF Classic API — device extension attribute updates
• Totara LMS — SFTP CSV export for learning path assignment
• Google Sheets (Apps Script) — audit trail for employee records

Security & deployment

• HMAC-SHA512 signature validation on all incoming HiBob webhooks.
• Dry-run mode for safe testing without triggering downstream side effects.
• Deployed via AWS SAM — Lambda (Python 3.12, 256 MB, 15s timeout) + API Gateway at /hibob/leavers.

Scheduled Lambda that reconciles Jamf's Mac device inventory against Snipe-IT SentinelOne licence seats. Automatically checks out seats for devices with the agent installed and alerts IT to any inventory discrepancies.

Workflow

• Authentication — Obtains a Jamf OAuth 2.0 token with automatic refresh on 401 and exponential backoff on rate limits.
• Device discovery — Fetches all computers from Jamf and retrieves detailed inventory including installed applications.
• Asset lookup — Queries Snipe-IT by serial number for each Jamf device; collects any serials not found for alerting.
• Licence checkout — If “SentinelOne Extensions.app” is present, automatically checks out a licence seat in Snipe-IT against the matched asset.
• SNS alert — Publishes a notification to an AWS SNS topic for any serial numbers that exist in Jamf but not in Snipe-IT, prompting manual review.

Environment variables

• jamf_client_id / jamf_client_secre — Jamf OAuth 2.0 client credentials.
• SnipeITAPIKey — Snipe-IT Bearer token.

Infrastructure

• AWS Lambda (Python 3.12), triggered on a schedule via CloudWatch Events.
• AWS SNS (eu-west-1) for unknown-serial IT alert notifications.
• Terraform IaC for Lambda function and IAM execution role.

Event-driven automation that automatically adds new starters to the correct Google Group when an onboarding Jira ticket transitions from Open to Work in Progress — eliminating manual IT admin work during employee onboarding.

Flow

Jira Automation rule (Open → Work in Progress) → POST webhook → API Gateway → Lambda → Google Admin SDK → Jira internal comment

Application overview

• Domain-based routing — Detects internal vs external users by email domain and routes to the correct Google Group automatically.
• Error surfacing — Any failure posts an internal comment directly to the Jira ticket with full detail on what went wrong, keeping gaps visible.
• Secure credentials — GCP service account credentials stored in AWS SSM Parameter Store with domain-wide delegation for Google Workspace access.
• Speed — End-to-end execution completes in under 3 seconds from ticket transition to group membership update.

Webhook payload

{
  "issueKey": "IT-789",
  "displayName": "Onboarding: Alex Johnson",
  "email": "[email protected]",
  "status": "Work in Progress"
}

Environment variables

• EXPECTED_SECRET — Shared secret for webhook validation.
• INTERNAL_GROUP_EMAIL — Google Group address for internal staff.
• EXTERNAL_GROUP_EMAIL — Google Group address for external users.
• INTERNAL_DOMAIN — Company email domain for internal/external routing.
• GCP_SERVICE_ACCOUNT_PARAM — SSM Parameter Store path for GCP service account JSON.
• JIRA_URL, JIRA_EMAIL, JIRA_API_TOKEN — Jira API credentials for internal comments.

Production thinking

• GCP service account JSON retrieved from SSM at runtime — no credentials in environment variables or code.
• Domain-wide delegation scoped to the minimum Google Admin SDK permissions required for group membership writes.
• Failure path posts back to the Jira ticket with a descriptive comment so no gap goes unnoticed.