Client: Keybase GIT with Continuous Integration

[ArtOfSettling]

Hello,

This isn't necessarily a bug, but how would the team suggest integrating Keybase with a continuous integration server.

So far, It's not currently possible with our CI Server (TeamCity) as TeamCity doesn't currently support remote helpers, I've filed a bug with JetBrains about this @ https://youtrack.jetbrains.com/issue/TW-51851

The way I saw this working was that I'd create an account with specific (restrictive) access to the appropriate repos, and install Keybase with that user on the continuous integration machine. I appreciate that there are a number of different solutions, hence I'm asking here for any recommended approaches.

[rikur]

+1

[delitescere]

I understand the need to cryptographically identify each device, but it is extremely bothersome in a world with infrastructure-as-code where a CI service might be being provisioned from scratch at any time (e.g. as a Docker container). Even if I keep pertinent parts of .local and .config on a host volume and keep the hostname consistent, the keybase login insists I have a new device that must be verified by another device.

Is there some mechanism of providing additional credentials (e.g. private key, paper key) to keybase login so automated systems can be keybase clients? Obviously those credentials should be held in an encrypted state by the provisioning system (e.g. in encrypted environment variables in Jenkins).

Otherwise, the use of keybase as a git repository for secrets becomes much less useful in an end-to-end continuous delivery pipeline. We have to duplicate those secrets in other systems (e.g. in encrypted environment variables in Jenkins).

This might be called "ephemeral device" support.

Thanks!

[dabura667]

We just copy the secret files so that everytime the docker is built it is initialized with a logged in keybase user.

No need to generate a new device every time.

[delitescere]

@dabura667 I tried that and alas it did not work for me. Which files do you copy? I used: .config/keybase/*.mpack and everything under .local

[junderw]

@delitescere Keybase login session info is stored in the next places:

/home/__nonrootuser__/.cache/keybase/session.json
/home/__nonrootuser__/.config/keybase/config.json
/home/__nonrootuser__/.config/keybase/secretkeys.__keybaseuser__.mpack
/home/__nonrootuser__/.local/share/keybase/__keybaseuser__.ss

Also, keybase commands can not be run by root, you will get an error. so if you run as user1, home folder should be user1 and all the above files should be chowned by user1:user1 also all of them are chmoded 0600 (rw for the user only)

[junderw]

@delitescere This works. Just tested it.
https://gist.github.com/junderw/d052ae7425aba640db4e72fd48b64124

You need to write in your own filenames though.

build the image, and you can spawn containers that start logged in as kbuser and allow you to run keybase commands as the user.

[junderw]

docker build -t kbdock:latest .
docker run -it kbdock /bin/bash
# some functions require you to run run_keybase each time you run the container.

[czerasz]

@junderw I think the link you provided has changed to https://gist.github.com/junderw/2de606d9969c768077308582cd4f7153

I have refactored it a little bit:

FROM debian:9.3

ARG KEYBASE_USER="KEYBASE_USER"

# Set env vars for linux user and keybase user
ENV LINUX_USER="keybase"

# Install curl to grab the latest build from keybase.io
RUN apt-get update && apt-get install -y \
    curl \
 && rm -rf /var/lib/apt/lists/*

# Create a user which will run keybase
RUN adduser --disabled-password --gecos "" $LINUX_USER

# Download the deb and install. exit 0 is to prevent build errors.
WORKDIR /home/$LINUX_USER
RUN curl -O https://prerelease.keybase.io/keybase_amd64.deb &&\
    dpkg -i keybase_amd64.deb || true &&\
    apt-get update &&\
    apt-get install -f -y &&\
    rm -rf /var/lib/apt/lists/* &&\
    rm keybase_amd64.deb &&\
    mkdir -p /home/$LINUX_USER/.cache/keybase/ \
             /home/$LINUX_USER/.config/keybase/ \
            /home/$LINUX_USER/.local/share/keybase/


# Copy the four files for the user session
COPY ./.cache/keybase/session.json /home/$LINUX_USER/.cache/keybase/session.json
COPY ./.config/keybase/config.json ./.config/keybase/secretkeys.$KEYBASE_USER.mpack /home/$LINUX_USER/.config/keybase/
COPY ./.local/share/keybase/$KEYBASE_USER.ss /home/$LINUX_USER/.local/share/keybase/$KEYBASE_USER.ss

# Make sure they are chowned and chmodded correctly
RUN chown -R $LINUX_USER:$LINUX_USER /home/$LINUX_USER/ &&\
    chmod 0600 /home/$LINUX_USER/.cache/keybase/session.json \
               /home/$LINUX_USER/.config/keybase/config.json \
               /home/$LINUX_USER/.config/keybase/secretkeys.$KEYBASE_USER.mpack \
               /home/$LINUX_USER/.local/share/keybase/$KEYBASE_USER.ss

# Run run_keybase to set up all the initial files and you will be logged in
USER $LINUX_USER

You can build it with docker build --build-arg=KEYBASE_USER=czerasz -t user/keybase-ci .

[ArtOfSettling]

I've successfully set this up with other CI's and all the info above is super useful!

If you guys are using TeamCity, I'd really appreciate your vote over at : https://youtrack.jetbrains.com/issue/TW-51851

👍

[dabura667]

Also be careful of config.json, as it contains hardcoded filepaths in your home folder, so if I log in with user abc on host and try to use that config file in a docker with kbuser, it will look for /home/abc instead and error out

[bootstraponline]

Implemented in https://github.com/keybase/client/pull/11500

I think this issue can be closed.

[maxtaco]

Great, LMK if not!