geschätzte Lesezeit: 2 min

geschätzte Lesezeit: 5 min

Bitwarden Secrets Manager and developers are a match made in security heaven — empowering fast moving development and DevOps teams to securely store, manage, and automate sensitive secrets required for deploying software. Programmatic machine access to these sensitive secrets is facilitated via

access tokens— granting machines within your ecosystem the ability to decrypt, edit, and create secrets. When developers store these access tokens in unsecured locations, however, they can be leveraged by bad actors attempting to steal sensitive data and access to your business environments. 

This guide will demonstrate how to securely store Bitwarden Secrets Manager access tokens and automate the session authentication process with Bash scripting in Linux desktop and MacOS environments.

Set up Bitwarden Secrets Manager

Before saving an access token with macOS keychain or Linux desktop, let’s configure Secrets Manager with a secret, project, and service account.

To start, open the Bitwarden Secrets Manager web app and create a new project. Projects are the primary way of grouping secrets and assigning access later. Choose a name for the project. For this demonstration, name the project Profile.

Next, create a service account. A service account represents non-human machine users that require access to a specific set of secrets. Name the service account CLI ACCESS.

Add the service account you just created to the existing project by navigating to the project and selecting the service accounts tab. The service account should have read, write access so that the administrator's Bash profile can properly access it.

From within your service account, generate a new access token by selecting the Access tokens tab. Give the access token a name, set expiration settings, and click New access token. Remember to copy the access token value for later and save it in a safe location; it cannot be retrieved again. 

Set up the Secrets Manager Command Line

Before you can securely store your access token with MacOs Keychain and Linux desktop for Bash scripting, you must first download the Bitwarden Secrets Manager CLI.

Download the Secrets Manager CLI client from GitHub and install the package on your machine. You can learn more about the Secrets Manager CLI in this help article.

Storing access tokens with MacOS Keychain

MacOS Keychain is an encrypted container for securely storing various types of confidential information, including Bitwarden Secrets Manager access tokens. More information on macOS Keychain can be found in Apple’s user documentation.

Create a Keychain item

Have the access token that was created in Secrets Manager on hand when following these steps. 

Open Keychain on your system and create a new Keychain item.

Name the item BWS_ACCESS_TOKEN.

In the Account Name field, enter the account you are using on your system. This will determine access to the key and the password required to use the key.

In the password field, input the access token that was previously created in the Secrets Manager GUI.

Once you are finished, select Add.

Inject access token into Bash script

Now return to the terminal and open .bash_profile. Insert your access token securely into the .bash_profile script.

Save and exit the text editor. Next, source the updated Bash profile to apply changes.

Now that the access token is set to an environment variable in your Bash profile, input your macOS user password to establish access to Bitwarden Secrets Manager. 

Test that the connection works by running the following command.

The project created during the earlier step should be returned as a JSON object in your terminal.

Storing access tokens with Linux desktop

Bitwarden Secrets Manager access tokens can also be securely stored with Bash scripting in Linux desktop environments using the GNOME keyring and libsecret-tool. Please note that this method does not work in a headless environment. 

Install GNOME Keyring, libsecret-tool and DBUS

The applications GNOME Keyring, lib secrets, and DBUS will be used to securely store the access token. GNOME Keyring is a software application integrated with the user’s login, allowing secrets, passwords, and keys to be made available for application access. GNOME Keyring will be used in conjunction with Libsecret, a library for securely storing and retrieving passwords and secrets. The application DBUS will help libsecret communicate with GNOME Keyring. Use the commands below to install these applications.

Inject access token into Bash script

The following command will store the access token with libsecret and GNOME Keyring:

When storing a secret with secret-tool, a label argument is required. This argument will be displayed in the secret-tool manager. For each secret stored, a unique attribute and value are required.

Here is an example of the populated command.

After entering the above command, the terminal will prompt you to submit a password on a single line. Enter the access token created previously in the Secrets Manager GUI and press enter.

A GUI popup will appear and ask for the access password to this key. Here you will set your preferred password to call this key in the future.

Check that the key was saved by entering the following command.

If the lookup returned your stored password, the key storage was successful. Next, open the .bash_profile where you wish to save the environment variable.

Save the following function in your script to lookup the BWS_ACCESS_TOKEN that was saved and run the function as an environment variable.

Save the changes and run the .bash_profile script in your terminal.

You will be prompted to enter the password you just set to secure your key. Once you have entered the password, test that the environment variable was properly created by running the following command.

The project created during the earlier step should be returned as a JSON object in your terminal. If the key storage was unsuccessful, or you would like to learn more about libsecret-tool, see the Ubuntu documentation. 

Start securing your developer pipeline with Bitwarden Secrets Manager

With Bitwarden Secrets Manager, developers have the tools they need to secure critical infrastructure secrets. See it in action and sign up for free or start a 7-day trial by contacting sales.

Developers

geschätzte Lesezeit: 3 min

Thank you for reading this far! Let’s connect. You can @ me on Twitter (@debilofant) with comments, or feel free to follow. Please like/share this article so that it reaches others as well.

geschätzte Lesezeit: < 1 min

NixOS 23.11’s nextcloud-client suffers from this. There is an easy work around to comment out a line, but I am not sure how I would do this in NixOS.

The problem is only cosmetic, but I run this on all the computers at my house and my family won’t understand “just cosmetic”.

I appreciate time anyone spends on this.

geschätzte Lesezeit: 12 min

It feels like forever since I wrote my Red Hat Enterprise Linux 8 Beta intro to Podman. In fact, it's been quite a while, and a lot has happened since then. For some time now, I've been planning on moving the Digital Ocean Droplet that hosts my sites from the CentOS 7 Docker platform to the CentOS 8 Podman platform. I would really love to do something more sophisticated, but to be honest, a single host running containers is all I need. So, I set out to move from the Docker Compose world to Podman.

docker-compose alternatives still emerging

I used Docker Compose for one simple reason: I can define my applications in a portable and easy-to-write YAML file, which gives me the ability to group each site with its dependencies. For instance, this site requires a web server running PHP and a database to store its data. Those are two containers, and managing them separately seems silly. Instead, I grouped them in a Docker Compose file. This solution allows me to work with the whole stack when I want to do things like stop services, or pull in updates for the container images I chose to use.

Pods

Well, moving to CentOS 8 meant replacing Docker with Podman. Podman does not have a counterpart to the docker-compose command. Well, it does, sort of. There's a project in the works called podman-compose, which is supposed to do the same basic thing as docker-compose. I wanted to find the "right" solution, though. Honestly, that was not an easy task. You'd think that a Google search for the "Podman counterpart to docker-compose " would get an article about how Podman replaces that functionality with something else. I couldn't find anything, though. What I did find was a reference to pods in Podman. Pods are a way of grouping containers together inside their own namespace, network, and security context. You can even start and stop the whole pod at once. The only thing it doesn't get me is a clean YAML file to define my services.

Note: I found this great example from Red Hat on pods, and it even touches on networking: Podman: Managing pods and containers in a local container runtime.

Podman play

Podman does, however, let you import Kubernetes definitions using the podman play command. Kubernetes definitions are YAML. It sounds like the solution for me. I spent some time trying to learn how to write these things and eventually came across the Kompose tool. Kompose converts docker-compose files into Kubernetes definitions. I thought it was perfect. Except it wasn't. What I needed specifically was a pod definition, and that's not what Kompose gave me. I might have been able to make a pod definition out of what I had, but I had another hunch.

Podman generate

Podman lets you generate Kubernetes definitions from the existing runtime. For example, if you have a running container, you can use podman generate to create a YAML file to define that container. You can also do that with a pod. So, I manually defined one of my WordPress sites in Podman.

Here are a few notes on that process.

Mapping ports

In the Docker world, ports are mapped to containers. That's true in Podman as well—except when you're running inside a pod. See, the pod is like a container of containers. Networking within the pod is more similar to networking within a host OS. Pods reach each other over the local host, and external networking reaches the pod, not the containers directly. When you run containers in a pod, you need to map ports on the pod like you would on the container in Docker or docker-compose. I also found that, although one of the benefits to Podman is the ability to run as a standard user, I had to do all of this as root because of some security problems I ran into when I created the pods. The problems were mainly centered around SELinux. I will likely circle back and try to re-do all of this without superuser privileges.

So, let's create a pod:

[gangrif@batou-lan ~]$ sudo podman pod create --name my-pod -p 8080:80
850425b9c02dc438a04c278196ef645fc9b8a27070a80d2c1d53aca0f1730502
[gangrif@batou-lan ~]$ sudo podman pod ls
POD ID         NAME     STATUS    CREATED         # OF CONTAINERS   INFRA ID
850425b9c02d   my-pod   Created   7 seconds ago   1                 b525a0511d3e

This command creates a pod with port 8080 mapped to inside port 80. If you then spin up a container listening on port 80, you'd have connectivity.

Create a container in the pod

To create a container in the pod, use podman run, but don't map a port. This makes more sense when you have more than one container to work with, so I'm going to create a database container and then a WordPress container.

[gangrif@batou-lan ~]$ sudo podman run \
-d --restart=always --pod=my-pod \
-e MYSQL_ROOT_PASSWORD="myrootpass" \
-e MYSQL_DATABASE="wp" \
-e MYSQL_USER="wordpress" \
-e MYSQL_PASSWORD="w0rdpr3ss" \
--name=wptest-db mariadb
Trying to pull registry.fedoraproject.org/mariadb...
  manifest unknown: manifest unknown
Trying to pull registry.access.redhat.com/mariadb...
  name unknown: Repo not found
Trying to pull registry.centos.org/mariadb...
  manifest unknown: manifest unknown
Trying to pull docker.io/library/mariadb...
Getting image source signatures
Copying blob 42ed51adaf49 done  
Copying blob 127c9761dcba done  
Copying blob 7e2d48f22ade done  
Copying blob a4a2a29f9ba4 done  
Copying blob 4039240d2e0b done  
Copying blob d13bf203e905 done  
Copying blob 6518a50ecb7c done  
Copying blob b5bc5a5c2503 done  
Copying blob 67412c7f89bc done  
Copying blob 58175d975ba9 done  
Copying blob 0c6efbafd3cb done  
Copying blob 1e18725209e8 done  
Copying blob 05202eb0846d done  
Copying config 22851c7fe9 done  
Writing manifest to image destination
Storing signatures
fed9756de1017a0ab38ff4b687a854af5422ec2c9fd13e175a78283426ccfc04
[gangrif@batou-lan ~]$ sudo podman run \
-d --restart=always --pod=my-pod \
-e WORDPRESS_DB_NAME="wp" \
-e WORDPRESS_DB_USER="wordpress" \
-e WORDPRESS_DB_PASSWORD="w0rdpr3ss" \
-e WORDPRESS_DB_HOST="127.0.0.1" \
--name wptest-web wordpress
Trying to pull registry.fedoraproject.org/wordpress...
  manifest unknown: manifest unknown
Trying to pull registry.access.redhat.com/wordpress...
  name unknown: Repo not found
Trying to pull registry.centos.org/wordpress...
  manifest unknown: manifest unknown
Trying to pull docker.io/library/wordpress...
Getting image source signatures
Copying blob f54006e0dc29 done  
Copying blob e0d3d1244592 done  
Copying blob eb2d00c10344 done  
Copying blob 8559a31e96f4 done  
Copying blob e0276193a084 done  
Copying blob 3a60f364b0c5 done  
Copying blob 8faf60068506 done  
Copying blob c59965a5777f done  
Copying blob 42c09ef39fe7 done  
Copying blob db37570cfdf4 done  
Copying blob 3e309988c00b done  
Copying blob 2c289722ebb3 done  
Copying blob e80a84c5a269 done  
Copying blob 491a234e2c26 done  
Copying blob b83f4c8507f7 done  
Copying blob 944a23d0ea39 done  
Copying blob a650de05eb1e done  
Copying blob a7780c30584c done  
Copying blob 267943a2fe25 done  
Copying blob ed59c3cd6acc done  
Copying config a5fef19f5a done  
Writing manifest to image destination
Storing signatures
A49711540329f4307ff218c277bb5a2848b37bf6ded922dfd2a839c564ddbdf1

Notice that I pointed the wordpress_db_host in the env: to localhost. That's because the WordPress container is going to find the database container on the local host. Like magic. Our pod has three containers. Yes, I ran two, but the third is the container that does the pod magic.

[gangrif@batou-lan ~]$ sudo podman pod ls
POD ID         NAME     STATUS    CREATED          # OF CONTAINERS   INFRA ID
850425b9c02d   my-pod   Running   12 minutes ago   3                 b525a0511d3e
And, as expected, podman ps gives us two containers.
[gangrif@batou-lan ~]$ sudo podman ps
CONTAINER ID  IMAGE                               COMMAND               CREATED        STATUS            PORTS                 NAMES
a49711540329  docker.io/library/wordpress:latest  apache2-foregroun...  2 minutes ago  Up 2 minutes ago  0.0.0.0:8080->80/tcp  wptest-web
fed9756de101  docker.io/library/mariadb:latest    mysqld                5 minutes ago  Up 5 minutes ago  0.0.0.0:8080->80/tcp  wptest-db

In my browser, I can get to the WordPress setup page in my container via localhost:8080.

The initial WordPress setup page is displayed. Success.

We're done, right? Nope. Now we want to make a YAML file that defines all of this.

Generate the YAML for our pod

We output our pod as a YAML definition by using podman generate kube command:

[gangrif@batou-lan ~]$ sudo podman generate kube my-pod >> my-pod.yaml
[gangrif@batou-lan ~]$ cat my-pod.yaml
# Generation of Kubernetes YAML is still under development!
#
# Save the output of this file and use kubectl create -f to import
# it into Kubernetes.
#
# Created with podman-1.9.3
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2020-07-01T20:17:42Z"
  labels:
    app: my-pod
  name: my-pod
spec:
  containers:
  - command:
    - apache2-foreground
    env:
    - name: PATH
      value: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
    - name: TERM
      value: xterm
    - name: HOSTNAME
      value: my-pod
    - name: PHP_MD5
    - name: PHP_VERSION
      value: 7.4.7
    - name: PHPIZE_DEPS
      value: "autoconf \t\tdpkg-dev \t\tfile \t\tg++ \t\tgcc \t\tlibc-dev \t\tmake
        \t\tpkg-config \t\tre2c"
    - name: APACHE_CONFDIR
      value: /etc/apache2
    - name: PHP_ASC_URL
      value: https://www.php.net/distributions/php-7.4.7.tar.xz.asc
    - name: PHP_EXTRA_BUILD_DEPS
      value: apache2-dev
    - name: PHP_CFLAGS
      value: -fstack-protector-strong -fpic -fpie -O2 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
    - name: WORDPRESS_VERSION
      value: 5.4.2
    - name: WORDPRESS_DB_NAME
      value: wp
    - name: WORDPRESS_DB_HOST
      value: 127.0.0.1
    - name: PHP_LDFLAGS
      value: -Wl,-O1 -pie
    - name: APACHE_ENVVARS
      value: /etc/apache2/envvars
    - name: WORDPRESS_DB_USER
      value: wordpress
    - name: PHP_CPPFLAGS
      value: -fstack-protector-strong -fpic -fpie -O2 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
    - name: PHP_URL
      value: https://www.php.net/distributions/php-7.4.7.tar.xz
    - name: PHP_INI_DIR
      value: /usr/local/etc/php
    - name: WORDPRESS_DB_PASSWORD
      value: w0rdpr3ss
    - name: PHP_EXTRA_CONFIGURE_ARGS
      value: --with-apxs2 --disable-cgi
    - name: PHP_SHA256
      value: 53558f8f24cd8ab6fa0ea252ca8198e2650160649681ce5230c1df1dc2b52faf
    - name: WORDPRESS_SHA1
      value: e5631f812232fbd45d3431783d3db2e0d5670d2d
    - name: GPG_KEYS
      value: 42670A7FE4D0441C8E4632349E4FDC074A4EF02D 5A52880781F755608BF815FC910DEB46F53EA312
    - name: container
      value: podman
    image: docker.io/library/wordpress:latest
    name: wptest-web
    ports:
    - containerPort: 80
      hostPort: 8080
      protocol: TCP
    resources: {}
    securityContext:
      allowPrivilegeEscalation: true
      capabilities: {}
      privileged: false
      readOnlyRootFilesystem: false
      seLinuxOptions: {}
    workingDir: /var/www/html
  - command:
    - mysqld
    env:
    - name: PATH
      value: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
    - name: TERM
      value: xterm
    - name: HOSTNAME
      value: my-pod
    - name: MARIADB_MAJOR
      value: "10.5"
    - name: MARIADB_VERSION
      value: 1:10.5.4+maria~focal
    - name: MYSQL_ROOT_PASSWORD
      value: myrootpass
    - name: MYSQL_USER
      value: wordpress
    - name: GOSU_VERSION
      value: "1.12"
    - name: GPG_KEYS
      value: 177F4010FE56CA3336300305F1656F24C74CD1D8
    - name: MYSQL_PASSWORD
      value: w0rdpr3ss
    - name: MYSQL_DATABASE
      value: wp
    - name: container
      value: podman
    image: docker.io/library/mariadb:latest
    name: wptest-db
    resources: {}
    securityContext:
      allowPrivilegeEscalation: true
      capabilities: {}
      privileged: false
      readOnlyRootFilesystem: false
      seLinuxOptions: {}
    workingDir: /
status: {}

I found that this output needed some cleanup. I deleted a bunch of the env: entries that I thought the container images would easily re-propagate, and in fact could cause conflicts if I were to build this again from scratch. Here's what I ended up with after editing:

# Generation of Kubernetes YAML is still under development!
#
# Save the output of this file and use kubectl create -f to import
# it into Kubernetes.
#
# Created with podman-1.9.3
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2020-07-01T20:17:42Z"
  labels:
    app: my-pod
  name: my-pod
spec:
  containers:
  - name: wptest-web
    env:
    - name: WORDPRESS_DB_NAME
      value: wp
    - name: WORDPRESS_DB_HOST
      value: 127.0.0.1
    - name: WORDPRESS_DB_USER
      value: wordpress
    - name: WORDPRESS_DB_PASSWORD
      value: w0rdpr3ss
    image: docker.io/library/wordpress:latest
    ports:
    - containerPort: 80
      hostPort: 8080
      protocol: TCP
    resources: {}
    securityContext:
      allowPrivilegeEscalation: true
      capabilities: {}
      privileged: false
      readOnlyRootFilesystem: false
      seLinuxOptions: {}
    workingDir: /var/www/html
  - name: wptest-db
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: myrootpass
    - name: MYSQL_USER
      value: wordpress
    - name: MYSQL_PASSWORD
      value: w0rdpr3ss
    - name: MYSQL_DATABASE
      value: wp
    image: docker.io/library/mariadb:latest
    resources: {}
    securityContext:
      allowPrivilegeEscalation: true
      capabilities: {}
      privileged: false
      readOnlyRootFilesystem: false
      seLinuxOptions: {}
    workingDir: /
status: {}

You can directly copy and paste the above content into your own file, and then use Podman to bring up exactly the same pod.

Bring up a pod from the YAML

Next, use podman play kube to start your pod from the defined YAML:

[gangrif@batou-lan ~]$ sudo podman pod ls
[gangrif@batou-lan ~]$ sudo podman ps
CONTAINER ID  IMAGE  COMMAND  CREATED  STATUS  PORTS  NAMES
[gangrif@batou-lan ~]$ sudo podman ps -a
CONTAINER ID  IMAGE  COMMAND  CREATED  STATUS  PORTS  NAMES
[gangrif@batou-lan ~]$ sudo podman play kube ./my-pod.yaml
Trying to pull docker.io/library/wordpress:latest...
Getting image source signatures
Copying blob 3a60f364b0c5 skipped: already exists  
Copying blob e0276193a084 skipped: already exists  
Copying blob 8559a31e96f4 skipped: already exists  
Copying blob f54006e0dc29 skipped: already exists  
Copying blob eb2d00c10344 skipped: already exists  
Copying blob e0d3d1244592 skipped: already exists  
Copying blob 8faf60068506 skipped: already exists  
Copying blob 3e309988c00b skipped: already exists  
Copying blob 42c09ef39fe7 skipped: already exists  
Copying blob c59965a5777f skipped: already exists  
Copying blob 2c289722ebb3 skipped: already exists  
Copying blob db37570cfdf4 skipped: already exists  
Copying blob 491a234e2c26 skipped: already exists  
Copying blob 944a23d0ea39 skipped: already exists  
Copying blob b83f4c8507f7 skipped: already exists  
Copying blob e80a84c5a269 skipped: already exists  
Copying blob 267943a2fe25 [--------------------------------------] 0.0b / 0.0b
Copying blob a7780c30584c [--------------------------------------] 0.0b / 0.0b
Copying blob ed59c3cd6acc [--------------------------------------] 0.0b / 0.0b
Copying blob a650de05eb1e [--------------------------------------] 0.0b / 0.0b
Copying config a5fef19f5a done  
Writing manifest to image destination
Storing signatures
Trying to pull docker.io/library/mariadb:latest...
Getting image source signatures
Copying blob 42ed51adaf49 skipped: already exists  
Copying blob 127c9761dcba skipped: already exists  
Copying blob 4039240d2e0b skipped: already exists  
Copying blob 1e18725209e8 skipped: already exists  
Copying blob d13bf203e905 skipped: already exists  
Copying blob 6518a50ecb7c skipped: already exists  
Copying blob 67412c7f89bc skipped: already exists  
Copying blob 7e2d48f22ade skipped: already exists  
Copying blob a4a2a29f9ba4 skipped: already exists  
Copying blob 58175d975ba9 skipped: already exists  
Copying blob 0c6efbafd3cb skipped: already exists  
Copying blob b5bc5a5c2503 [--------------------------------------] 0.0b / 0.0b
Copying config 22851c7fe9 done  
Writing manifest to image destination
Storing signatures
Pod:
a91dc8859e85505b43f82f1be248880f76138f0ae86f12c3ffdea4d309d4eacf
Containers:
87a67588fbacf959c95f8f63f9f26ffa7b4fb3c7f8827aadd65bcd94de526e37
cc3f3e7255c8110826565673b5d30ebc223cbfcefa01597714231e1305382d3c
[gangrif@batou-lan ~]$ sudo podman pod ls
POD ID         NAME     STATUS    CREATED          # OF CONTAINERS   INFRA ID
a91dc8859e85   my-pod   Running   10 seconds ago   3                 aa53c9308991
[gangrif@batou-lan ~]$ sudo podman ps
CONTAINER ID  IMAGE                               COMMAND               CREATED         STATUS             PORTS                 NAMES
cc3f3e7255c8  docker.io/library/mariadb:latest    docker-entrypoint...  12 seconds ago  Up 11 seconds ago  0.0.0.0:8080->80/tcp  wptest-db
87a67588fbac  docker.io/library/wordpress:latest  docker-entrypoint...  13 seconds ago  Up 12 seconds ago  0.0.0.0:8080->80/tcp  wptest-web

And if you hit up port 8080, you should get the WordPress setup page, just like before.

Conclusion

I hope this post is helpful. It took me some time to figure out, so I thought it was worth sharing. Happy podmanning.

[ Getting started with containers? Check out this free course. Deploying containerized applications: A technical overview. ]