Categorygithub.com/hozalex/knox
modulepackage
0.0.0-20220116124430-3492e0ae15bf
Repository: https://github.com/hozalex/knox.git
Documentation: pkg.go.dev

# README

Knox -- the high level overview

Knox is a service for storing and rotation of secrets, keys, and passwords used by other services.

The Problem Knox is Meant to Solve

Pinterest has a plethora of keys or secrets doing things like signing cookies, encrypting data, protecting our network via TLS, accessing our AWS machines, communicating with our third parties, and many more. If these keys become compromised, rotating (or changing our keys) used to be a difficult process generally involving a deploy and likely a code change. Keys/secrets within Pinterest were stored in git repositories. This means they were copied all over our company's infrastructure and present on many of our employees laptops. There was no way to audit who accessed or who has access to the keys. Knox was built to solve these problems.

The goals of Knox are:

  • Ease of use for developers to access/use confidential secrets, keys, and credentials
  • Confidentiality for secrets, keys, and credentials
  • Provide mechanisms for key rotation in case of compromise
  • Create audit log to keep track of what systems and users access confidential data

Read more at https://github.com/pinterest/knox/wiki

Getting knox set up

The first step is to install Go (or use Docker, see below). We require Go >= 1.6 or Go 1.5 with the vendor flag enabled (GO15VENDOREXPERIMENT=1). For instructions on setting up Go, please visit https://golang.org/doc/install

After Go is set up (including a $GOPATH directory that will store your workspace), please run go get -d github.com/pinterest/knox to get the latest version of the knox code.

To compile the devserver and devclient binaries, run go install github.com/pinterest/knox/cmd/dev_server and go install github.com/pinterest/knox/cmd/dev_client. These can be directly executed, the dev_client expects the server to be running on a localhost. By default, the client uses mTLS with a hardcoded signed cert given for example.com for machine authentication and had github authentication enabled for users.

To start your server run:

$GOPATH/bin/dev_server

For using this client as a user, generate a token via these instructions https://help.github.com/articles/creating-an-access-token-for-command-line-use/ with read:org permissions. This token will be able to get your username and the organization you belong to. With the dev_server running you can now create your first knox key.

export KNOX_USER_AUTH=<insert generated github token here>
echo -n "My first knox secret" | $GOPATH/bin/dev_client create test_service:first_secret

You can retrieve the secret using:

$GOPATH/bin/dev_client get test_service:first_secret

You can see all key IDs using:

$GOPATH/bin/dev_client keys

To see all available commands run:

$GOPATH/bin/dev_client help

For production usage, I recommend making your own client, renaming it knox, and moving it into you $PATH for ease of use.

For more information on interacting with knox, use knox help or go to https://github.com/pinterest/knox/wiki/Knox-Client

Knox with Docker

You can run a Docker container to get knox set up, instead of installing Go on your host.

git clone https://github.com/pinterest/knox.git
cd knox
docker run --name knox --rm -v "$PWD":/go/src/github.com/pinterest/knox -it golang /bin/bash

This will run a bash shell into the container, mounting a local copy of knox in the go source path.

You can refer back to the section "Getting knox set up" to set up knox.

# Packages

No description provided by the author
No description provided by the author
Package log implements a simple logging package.
No description provided by the author

# Functions

GetBackoffDuration returns a time duration to sleep based on the attempt #.
MockClient builds a client that ignores certs and talks to the given host.
NewClient creates a new client to connect to talk to Knox.
NewFileClient creates a file watcher knox client for the keyID given (it refreshes every ten seconds).
NewMock is a knox Client to be used for testing.
NewMockKeyVersion creates a Knox KeyVersion to be used for testing.
NewPrincipalMux returns a Principal that represents many principals.
Register registers the given keyName with knox.
ServicePrefixPathComponentsValidator is an extra validator that can be applied to ensure that service prefixes have a certain minimum length, e.g.

# Constants

Active represents Key Versions still in use, but not Primary.
Admin denotes the ability to delete the key and modify the ACL.
These are the error codes for use in server responses.
These are the error codes for use in server responses.
These are the error codes for use in server responses.
Inactive represents Key Versions no longer in use.
These are the error codes for use in server responses.
These are the error codes for use in server responses.
These are the error codes for use in server responses.
These are the error codes for use in server responses.
Machine represents the host of a machine.
MachinePrefix represents a prefix to match multiple machines.
These are the error codes for use in server responses.
These are the error codes for use in server responses.
None denotes no access.
These are the error codes for use in server responses.
These are the error codes for use in server responses.
These are the error codes for use in server responses.
Primary is the main key version.
Read denotes the ability to read key data.
Service represents a service via SPIFFE ID.
ServicePrefix represents a prefix to match multiple SPIFFE IDs.
These are the error codes for use in server responses.
These are the error codes for use in server responses.
Unknown represents a bad PrincipalType that cannot be marshaled.
User represents a single LDAP User.
UserGroup represents an LDAP security group.
Write denotes the ability to add key versions and perform rotation.

# Variables

No description provided by the author
No description provided by the author
No description provided by the author
No description provided by the author
No description provided by the author
No description provided by the author
No description provided by the author
No description provided by the author
No description provided by the author
No description provided by the author
No description provided by the author
No description provided by the author
No description provided by the author
No description provided by the author
No description provided by the author
No description provided by the author
No description provided by the author
No description provided by the author

# Structs

Access is a specific access grant as a part of an ACL specifying one principal's or a group of principals' granted acccess.
HTTPClient is a client that uses HTTP to talk to Knox.
Key represents the Primary element of Knox.
KeyVersion is a specific version of a Key.
PrincipalMux provides a Principal Interface over multiple Principals.
Response is the format for responses from the api server.

# Interfaces

APIClient is an interface that talks to the knox server for key management.
Client is an interface for interacting with a specific knox key.
No description provided by the author
Principal is a person, machine, or process that accesses an object.

# Type aliases

AccessType represents what kind of Access is granted in a key's ACL.
ACL is a list of access information that provides authorization information for a specific key.
KeyVersionList represents the list of versions of a key.
PrincipalType is an attribute of ACLs that specifies what type of Principal is represented.
A PrincipalValidator is a function that applies to a principal type and string, and validates that the string is a valid principal for the given type.
VersionStatus is an enum to determine that state of a single Key Version.