MZDevOps / DevSecOps Engineer

Open to remote roles · PL / EU

Marcin Żelasko

DevOps / DevSecOps Engineer · Zielona Góra, PL

I build and secure AWS infrastructure for product teams. Everything as code, observable and audit-ready.

7+Years in DevOps
150+AWS accounts secured
3Certifications

01 / Profile

I'm a self-taught engineer who likes making the boring parts of infrastructure disappear.

My favourite work is self-service: tools and code that let other teams help themselves. Most recently I brought a GitHub organisation under Terraform, and teams now open pull requests for what they need on their own.

It isn't always a tool. Sometimes the job is explaining how a new AWS organisation works, so developers can move to it with confidence. When it is a tool, AI coding assistants make building small internal ones quicker than ever.

Next, I'd like to go deeper into platform engineering: building the paved roads other teams ship on.

02 / Experience

Nov 2023 – present

DevSecOps Engineer

CodetainZielona Góra

  • Migrating manually configured Cloudflare settings to infrastructure as code, so changes are reviewed, versioned and reproducible.
  • Built and automated the process that lets backend APIs onboard to Cloudflare API Shield (about 80 APIs onboarded).
  • Built automated monitoring and alerting for security findings across 80+ AWS accounts (Datadog and AWS Security Hub).
  • Work directly with developer teams to triage and fix security issues (Docker image scanning, static code analysis).

May 2022 – Oct 2023

DevOps Engineer

XenetaOslo

  • Improved AWS security across the organisation and implemented SSO.
  • Remediated multiple findings from Datadog Cloud Security Posture Management.
  • Rolled out Datadog monitoring across the AWS organisation.
  • Built CI/CD pipelines in Jenkins.
  • Helped scale ECS and Lambda workloads across the AWS organisation.
  • Migrated AWS infrastructure to Terraform across multiple AWS accounts.

Aug 2019 – May 2022

DevOps Engineer

CodetainZielona Góra

  • Operated cloud-based applications, with infrastructure defined in Terraform and CloudFormation.
  • Owned CI/CD in CircleCI: unit tests and automated deployments in the pipeline.
  • Wrote Python and Bash scripts that replaced manual tasks.
  • Automated server provisioning and configuration management, giving faster deployments and easier maintenance.
  • Worked closely with development teams while the software was being built.

03 / Selected work

Case study 01

Self-service API Shield onboarding

~80 APIs onboardedCloudflare API ShieldOpenAPIPythonCircleCI

Turned a manual, per-API Cloudflare setup into one step in every team's deploy pipeline.

Problem
Dozens of backend APIs sat behind Cloudflare, but only a handful had schema validation, each uploaded by hand: the OpenAPI file, every endpoint, the action for invalid requests. It did not scale, it went stale as soon as an API changed, and an outdated schema risked blocking legitimate traffic to new endpoints.
Approach
I built a small Python tool that product teams call from their own CircleCI pipelines, passing in the OpenAPI file they already maintain. Before a deploy, it switches the service to log-only, so routes that are about to change are not blocked mid-rollout. After the deploy, it replaces the schema for that service and environment, registers every operation with endpoint management and turns enforcement back on. API calls retry on transient errors and page through every operation, so a large API or a flaky response does not leave it half-configured.
Result
About 80 APIs onboarded without teams touching the Cloudflare dashboard. Every deploy keeps the schema in step with the code that is actually running, removed endpoints drop out on their own, and enforcement only tightens once the new version is live. Schema validation now regularly stops invalid requests at the edge, before they reach the services.
A deploy

Team pipeline (CircleCI)

The service's own pipeline pulls in the shared tool and hands it the OpenAPI file the team already maintains.

Case study 02

Weekly rotation for shared DNS tokens

7 tokens rotated weeklyAWS LambdaSecrets ManagerKMSTerraformPython

Shared Cloudflare DNS tokens that had never been rotated now get a new value every week, without any team changing its pipelines.

Problem
Infrastructure pipelines in many AWS accounts create DNS records in Cloudflare through Terraform and CloudFormation. They shared seven Cloudflare API tokens, already handed out through Secrets Manager, but the tokens never changed: a leaked one would keep working indefinitely. Any rotation had to happen without asking each team to update anything.
Approach
A Python Lambda, started weekly for each token by EventBridge, rolls the token through the Cloudflare API with a separate management token and publishes the new value as the current version of its secret. Terraform defines the rest: the token-to-secret mapping, the schedules, secret and key policies for cross-account reads, customer managed KMS keys and replicas in a second region. Every run reports to Slack, and GitHub Actions deploys the Lambda through OIDC, with no long-lived AWS keys. Pipelines already fetched the secret on every run and kept no copy between runs, so rotation could live in one place.
Result
Seven tokens that had never been rotated now rotate weekly, readable from 49 AWS accounts, with three of them replicated to a second region. No team changed a thing: the next pipeline run simply picks up the new value. Replication taught me the most. Reading a secret, decrypting it and replicating it are separate permissions, and a replica is encrypted with a key in its own region. The fix was giving the rotation role both regional keys and adding data-key generation to the shared key policy.
A rotation

Schedule (EventBridge)

A weekly rule for each token invokes the Lambda with the token ID and its destination secret. Only identifiers travel in the event, never a credential.

Side project 03

This site, run like production

98–100 Lighthouse scoresCloudflare WorkersTerraformGitHub ActionsContent Security Policy

This site runs the way I run production: everything as code, reviewed before it ships, locked down by default.

Problem
A portfolio is a small static page, but it is also a public sample of how I work. Set up the usual way, its DNS, redirects and email would be clicked together in dashboards, deploys would skip review, and security headers would be an afterthought.
Approach
Terraform manages DNS, the custom domain, the www redirect, email routing and TLS settings, with state in Cloudflare R2. The page is prerendered and served by Cloudflare Workers, only on its own domain. Every pull request runs the tests, the build, a Wrangler dry run and a Terraform plan posted as a comment; merging deploys, applies and smoke-tests production. A strict Content Security Policy allows the one inline script by its hash.
Result
A change is live about a minute after merging, checked by a smoke test against production. Lighthouse scores 98 to 100 across performance, accessibility, best practices and SEO. The headers below are the real ones, read from the same file Cloudflare serves.

Browser (HSTS)

After the first visit, HSTS tells the browser to use HTTPS only, for two years and for every subdomain. The header also opts in to the preload list.

Response headers on every page
$ curl -sI https://marcinzelasko.comcontent-security-policy: default-src 'self';script-src 'self' 'sha256-flGvizFYDdITDPWeoYbtMujI0araP3UO5e7/nYLzc2I=' https://static.cloudflareinsights.com;style-src 'self';font-src 'self';img-src 'self' data:;connect-src 'self' https://cloudflareinsights.com;frame-ancestors 'none';base-uri 'self';form-action 'none'strict-transport-security: max-age=63072000;includeSubDomains;preloadx-content-type-options: nosniffreferrer-policy: strict-origin-when-cross-originpermissions-policy: camera=(), microphone=(), geolocation=()

04 / Stack

Multi-account organisations, their security posture and the workloads inside them.

Security and governance 09

  • OrganizationsSecuring multi-account organisations, 150+ accounts in total
  • Security HubFindings from 80+ accounts routed into automated alerts
  • IAM Identity CenterOrganisation-wide SSO for AWS
  • CloudTrailOrganisation trails, investigated with Athena queries
  • GuardDutyThreat findings centralised across accounts
  • ConfigCompliance rules and alerting, organisation-wide
  • Secrets ManagerWeekly token rotation, shared across accounts and regions
  • IAM
  • KMS

Compute and containers 04

  • ECRRegistries with lifecycle rules and image scanning
  • ECS
  • Lambda
  • EventBridge

Networking, storage and monitoring 04

  • VPC
  • Route 53
  • S3
  • CloudWatch

05 / Certifications

Languages: Polish (native) · English (C1)

06 / Contact

hi@marcinzelasko.com
LinkedIn Zielona Góra, PL