Posted on

1PassMapper – updated.

Not too long ago, we published this article about the 1PassMapper.
( article: https://emberlabs.tech/2025/09/18/1passmapper )

Guess what?
It just got updated with a couple of new items to make it even more powerful!

We just added the flags -prefix <path> and -token <filename> .

The -prefix allows you to have the same build script prepend the source paths in the template, using a single template for all your environments, instead of multiple files, moving the prefix of the path into an argument.

In the template, you would use something like [[some.path.to.cred]],  and with the -prefix dev , the real path would be: [[dev.some.path.to.cred]].

Replace the `-prefix dev` with -prefix prod, and now, you would use the “prod” source path in your credentials file.

The -token <filename>` ?  – this is how you can easily switch from using the default 1Password token file to some other token file allowing you the use of multiple 1Password accounts for different needs.

Get your team onboard with keeping the creds out of the GIT!

Get your copy today – It’s free!
https://github.com/emberlabstech/1PassMapper

Njoy!!

 

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!