Posted on

1PassMapper

Securing Your Development & Deployments with 1PassMapper

Source: https://github.com/emberlabstech/1PassMapper

At EmberLabs®, security has always been at the heart of how we design, build, and deploy software.
One recurring challenge for Dev/DevOps teams is keeping the security of credentials with the practical need for configuration during builds and deployments, while just going about doing their day to day work. 

Far too often, secrets end up hardcoded in Git repositories and code, CI/CD pipelines, or configuration files – creating risks that can later become costly breaches.

This is where 1PassMapper comes in.


Why 1PassMapper?

Modern development teams rely heavily on automation.
Whether you’re deploying Docker containers, Kubernetes workloads, or traditional servers, there is always a need to inject API keys, database passwords, and certificates at “runtime” or build of deployment.

The problem:

  • You want to keep your configuration templates versioned in Git.

  • You do not want to commit sensitive credentials.

  • You want to maintain credentials and settings in a single location, but used in many locations – Single update.
  • When credentials (or other data) rotate, you need builds to automatically reflect those changes.

  • You may need different credentials for different environments without duplicating templates.

1PassMapper solves this by bridging your templates and secure vaults (like 1Password).


How It Works

1PassMapper allows you to:

  • Define your configuration files as templates (with tags like [[sql.host]]).

  • Store credentials in a JSON object either locally or inside a 1Password vault item.

  • Automatically map placeholders in your templates to the correct secret or configuration values during your build process.

This means your Git repository contains only clean templates with placeholders, while the real secrets live securely in 1Password.

Example:

Template (sample-template.json):

{
    "item1": "[[sql.host]]",
    "item2": "[[sql.user]]",
    "item3": "[[sql.pass]]",
    "item4": "[[host.domain]]",
    "item5": "[[cred.UNKNOWN]]"
}
Credentials (in 1Password or a local JSON file):
{
  "sql": {
    "host": "some.domain",
    "port": "3306",
    "user": "root",
    "pass": "someAwesomePassword"
  },
  "host": {
    "domain": "myCoolDomain.com",
    "port": "443",
    "certKey": "certificate.key",
    "cert": "certificate.pem",
    "certpass": "myKeyPassword"
  }
Practical example – build from 1Password CICD/MySecretItem, 
1PassMapper -in sample-template.json -out config.json -vault CICD -item MySecretItem
or, using a local file:
1PassMapper -injson sampleJsonCreds.json -in sample-template.json -out config.json

Build output (config.json):

{
    "item1": "some.domain",
    "item2": "root",
    "item3": "someAwesomePassword",
    "item4": "myCoolDomain.com",
    "item5": "[[cred.UNKNOWN]]"
}
Your secrets never touch Git, and you can freely reuse the same template across environments.

Security Benefits

  • Eliminates hard-coded secrets from Git, Code in general, and possibly Docker images.

  • Centralizes credential storage in 1Password with audit trails and rotation policies.

  • Supports environment isolation (dev, staging, prod) with the same templates, using the Makefile or similar, to determine the template used.

  • Provides consistency across local builds and CI/CD pipelines, by using the same key for common items. 


Development Benefits

  • Less hassle: new developers pull templates without worrying about leaking secrets.
    Just map a key to a secret – it’s reusable!

  • Deduplication: Provides a way to use values, provided by by namespaces, leading to less duplication.
  • Flexibility: supports Json, Yaml, or any other textbased configuration formats, including code. 

  • Resilient pipelines: secrets update automatically when rotated in 1Password.

  • Portability: build in the cloud or locally with the same tooling.


Why EmberLabs® Built This

At EmberLabs®, we wanted a solution that was:

  • Lightweight and developer-friendly.

  • Flexible enough to handle multiple environments.

  • Strongly aligned with secure-by-design principles.

With 1PassMapper, we created a tool that is fast and simple, and integrates seamlessly into existing DevOps workflows,
with the aim to give teams confidence that their deployments are both secure and repeatable, and offers a way to reduce
configuration duplication as an added bonus. 


Summing it up.

In 2025, development speed can’t come at the cost of security. Seriously.
With 1PassMapper, teams can have both: secure credential management and streamlined deployments.

If your organization struggles with keeping secrets safe while maintaining efficient builds, this approach may change how you think about DevSecOps practices.

🔒 Secure your pipelines.
⚡ Accelerate your workflows.
✅ Standardize your deployments.

© EmberLabs® (BY-SA)

Enjoy!

Posted on

Handling gaps in Your CV as a contractor or self-employed professional

TL;DR:
Register a trading name (and TM), use it as your employer on your CV, describe your roles, and treat clients as projects, not jobs.
This provides a seamless, professional timeline—no gaps, and full legitimacy.

The longer reasoned version…
If you are looking for a new position, gaps in your CV can raise questions, especially if you work as a contractor or are self-employed.

Here’s a practical approach, that can solve these issues, and provide a solid timeline.

  1. Register a Trading Name:
    Even as a sole trader, register a trading name for your business. In most countries, this is inexpensive and can also be registered as a trademark (™), giving your business added credibility. Just choose the trading name you want to work with, and typically, within EU, a national registration is ~100 euro.
    This also gives you a VERY strong legal protection for your trading name, and you can prevent others from using it in your class.
    It is even stronger protection than registering a busines name with the companies house…
    Also, register this as a “wordmark” for maximum protection, as this enables you to incorporate the name in any graphical setting, as otherwise, a trademark would be linked and limited to the specific graphical representation that has been registered, as a wordmark allows you to use it in ANY graphical, logo or font setting, as it is the “word” itself that is protected, not how it is represented.

  2. Trade Under Your Registered Name:
    Conduct all your business activity using your trading name.
    Use this name consistently on all invoices, contracts, and professional correspondence.

  3. Present Your Trading Name as Your Employer:
    On your CV, list your trading name (and TM, if registered) as your employer.
    Your self-employment under your own company or trading name is a perfectly valid and legal form of employment, and way of representing yourself on the market.

  4. List Roles, Not Clients:
    Instead of listing each client as a separate employer, describe your roles and responsibilities under your trading name, and optionally mention key clients or projects as examples.
    This creates a single, continuous timeline of employment and avoids unexplained gaps.

Example:

Period Employer Role Details
2015–Present ACME Consulting™ Owner/Consultant Provided IT consulting to various clients…
[list of clients, and summary types of work / roles for the clients]

The benefits?

  • Ensures a consistent work history with no unexplained gaps.

  • Enhances professional image with a registered TM.

  • Allows you to maintain confidentiality about clients if needed.

  • Factually correct: Self-employment under a trading name is a legal form of employment.

  • Common practice: Many experienced contractors use this method to avoid the appearance of gaps.

  • Protects client confidentiality and avoids cluttering the CV with short stints.

  • Removes bias – Employers often hesitate if they see gaps or too many short contracts; this format presents stable, ongoing work.

Possible caveats?

  • Some HR may request clarification about what you did for that period—be ready with a project/client list if asked.
    Any non-client periods, can be explained as self-investment in training, working on internal products and otherwise.

  • In some industries (e.g., government, finance), disclosure of clients may still be required at later stages.
    This is technically not a problem, and you would have the invoicing and other items to show, as well as self-investment as cover for gaps.

Good luck!

Posted on

Another step on the road.

I got the A1-A3 and A2 drone license.
(and I’m not stopping there…)
Got around to doing the second part, going for the A2, and if you are thinking of getting your drone training and license, take a look here:
https://www.dronelicense.eu/

Very good and effective training material, allowing you to work at your own pace, and most importantly,
get there, and get properly licensed across EU.

  • It’s formal,
  • It’s real,
  • It’s official.
  • It’s valid across all of EU.
    (please note that you will need to register as a pilot in at least one EU country, and some require individual national registrations)

Ok, ok… so what are the rules?!

You can effectively sum it up as:

  • A1: fly over people but not over assemblies of people
  • A2: fly close to people
  • A3: fly far from people (heavyweight drones are limiting this)

This is a EASA (European Aviation Safety Agency) summary of drone classes and rules. 

EASA information:
https://www.easa.europa.eu/en/domains/drones-air-mobility/operating-drone/open-category-low-risk-civil-drones