DEV Community: nownabe

Sekret: Encryption tool for Kubernetes Secrets

nownabe — Mon, 27 Aug 2018 10:36:41 +0000

Sekret is a CLI tool to encrypt and edit Kubernetes Secrets. Sekret makes management and deployment for Secret secure and simple.

Motivations

want version controlled Secret like other resources (e.g., deployments)
want to commit encrypted Secret YAMLs
want to edit encrypted Secret YAMLs easily
want to apply decrypted Secret YAMLs easily

Functionalities

Encrypt plain YAMLs
Decrypt encrypted YAMLs
Create new encrypted Secret YAMLs
Edit encrypted Secret YAMLs as plain text

Demo

Installation

You can get Sekret with go get.

go get github.com/nownabe/sekret

Also, you can download binaries from GitHub Releases.

curl -sSL -o /path/to/sekret https://github.com/nownabe/sekret/releases/download/v1.1.0/sekret_linux_amd64
chmod +x /path/to/sekret

Usage

sekret command is used following subcommands enc / dec / new / edit.

sekret subcommand [options] filename

The environment variable ENCRYPTION_KEY is used as the encryption key for all subcommands. Encryption keys must be 16 or 32 bytes. EDITOR variable specifies the editor for new and edit subcommands. Command options can also specify them.

Encrypt

Following commands encrypt secret.yaml and then commit it on Git.

$ export ENCRYPTION_KEY=$(cat /dev/urandom | base64 | fold -32 | head -1)
$ sekret enc secret.yaml > secret.yaml.enc
$ git add secret.yaml.enc
$ git commit

Decrypt

Easy to decrypt and apply Secrets.

$ sekret dec secret.yaml.enc | kubectl apply -f -

Create New Encrypted Secrets

new subcommand creates a new encrypted Secret YAMLs.

$ export EDITOR=vim
$ sekret new secret.yaml.enc

sekret new opens specified editor with the Secret template like following YAML.

apiVersion: v1
data:
  Key: Value
kind: Secret
metadata:
  creationTimestamp: null
  name: new-secret
type: Opaque

Values of data must be encoded as base64 in Kubernetes Secrets, but sekret encodes and decodes automatically on opening and saving them. So you can write YAML as completely plain text. If you want to edit as base64, use --decode-base64=false option.

Sekret validates before saving YAML, so it doesn't save YAML when invalid.

Edit Encrypted Secrets

You can edit encrypted Secret YAML like plaintexts with edit subcommand.

$ sekret edit secret.yaml.enc

sekret edit opens decrypted and base64 decoded YAML in the specified editor. When the editor is closed, it saves encrypted and base64 encoded YAML. Of course, it validates YAML before saving.

Conclusion

Sekret makes lifecycle of Sekret very simple and secure. It is effortless to manage and deploy Secret YAML.

Secure User in Docker

nownabe — Wed, 20 Jun 2018 06:18:38 +0000

TL; DR

Create users in Dockerfile as following:

RUN groupadd -g 61000 docker
RUN useradd -g 61000 -l -M -s /bin/false -u 61000 docker

Secure User in Docker

Running docker container as a root user is risky because the root user in containers has same uid 0 as the host root user. So you have to change the user in containers to non-root user as possible.

Most simple and effective way is to create a user in Dockerfile. For example:

FROM debian

RUN useradd docker
USER docker

CMD ["bash"]

You can also change the user with -u option of docker run. With Kubernetes, you can use SecurityContext to modify the user.

This Dockerfile is fine, but useradd has many options. Let me describe which options should be used in Dockerfile.

Options often used with Dockerfile are:

$ useradd --help
Usage: useradd [options] LOGIN
       useradd -D
       useradd -D [options]

Options:
  -g, --gid GROUP               name or ID of the primary group of the new
                                account
  -l, --no-log-init             do not add the user to the lastlog and
                                faillog databases
  -m, --create-home             create the user's home directory
  -M, --no-create-home          do not create the user's home directory
  -r, --system                  create a system account
  -s, --shell SHELL             login shell of the new account
  -u, --uid UID                 user ID of the new account
  -U, --user-group              create a group with the same name as the user

Let's review each option.

-g specifies uid. Because the same gid as uid is easy to understand, you should use -g.
-l looks good because lastlog and faillog have few meanings.
If you have to operate with shell in containers¹, use -m to create home directory. If not, use -M.
-r option makes user as a system account. uid is configured from /etc/login.defs and home directory doesn't be created. You should not use this option because you will use -u to specify uid and use -m/-M to configure home directory.
-s /bin/false can forbid remote login. You can execute shell with docker exec -u $uid sh, even if /bin/false or /bin/nologin is set. This option might protect from direct remote login, so you should use -s /bin/false.
-u specifies uid. When -u was not used, uid is assigned automatically. To manage simply, you should use this option.
-U creates a group named same as the user but gid can differ from uid. -g is preferred to -U.

In conclusion, you should use following instructions to create users:

RUN groupadd -g 61000 docker
RUN useradd -g 61000 -l -M -s /bin/false -u 61000 docker

If you need home directory:

RUN groupadd -g 61000 docker
RUN useradd -g 61000 -l -m -s /bin/false -u 61000 docker

Because major distributions reserve uid from 1000 to 60000, I proposed 61000 as uid. By the way, worker nodes of GKE reserve uid from 5000 to 60000. If you use 5000 as uid, they conflict.

For example, you often use bundle exec rails console. ↩