a.k.a. API tokens are so 2012
The HSCloud Public Key Infrastructure system is a lightweight specification on how microservices within the HSCloud ecosystem authenticate themselves.
The driving force behind this being standardized is to make it very easy for developers to write new microservices and other tools that can mutually authenticate themselves without having to use public TLS certificates, API tokens or passwords.
Each microservice or tool has a key/certificate pair that it uses to both serve incoming requests and to use as a client certificate when performing outgoing requests.
We currently support gRPC as a first-class transport. Other transports (HTTPS for debug pages, HTTPS for JSON(-RPC)) are not yet implemented.
The distribution of HSPKI certificates to production services is currently being designed (and will likely be based on Hashicorp Vault or a similar NIH tool). For development purposes, the gen.sh script in dev-certs/ can be used to generate a temporary CA, service keypair and developer keypair.
All certs for mutual auth have the following CN/SAN format:
<job>.<principal>.svc.<cluster-short>.<realm> or <principal>.person.<realm> or <principal>.external.<realm>
Where in adition we define <cluster> as being <realm> plus its next left-side member.
For example, for kubernetes jobs:
foo.bar.svc.k0.hswaw.net job = foo principal = bar.svc cluster = k0.hswaw.net realm = hswaw.net
Where foo is the name of a kubernets service, bar is the name of the namespace its in, and k0.hswaw.net is the cluster running them.
For people and external services:
q3k.person.hswaw.net job = principal = q3k cluster = person.hswaw.net realm = hswaw.net
The Realm is a DNS name that is global to all jobs that need mutual authentication.
The Principal is any name that carries significance for an authentication principal, ie. a unit that gives information about an identity of an element. In case of kubernetes it's a namespace (as we split authentication/authorization into namespaces). In the case of external services and people it's the name of the service or person.
The Job is a name that makes the Principal more specific, if possible. If set, the Principal can be treated as a group of Jobs.
The entire CN should be DNS resolvable into an IP address that would respond to gRPC requests on port 42000 (with a server TLS certificate that represents this CN) if the job represents a service.
Currently you'll have to manually check the PKI information via your language's library and reject unauthorized access within your handler. A unified ACL system with an external RBAC store is currently being designed.
We provide a Go library that all microservices should use to interact with HSPKI.
In lieu of a godoc (soon (TM)), here's a quick usage example:
import (
"code.hackerspace.pl/hscloud/go/pki"
)
...
g := grpc.NewServer(pki.WithServerHSPKI()...)
pb.RegiserXXXServer(g, service)
...
Once linked into your program, the following flags will be automatically present:
-hspki_cluster string
PKI realm (default "svc.cluster.local")
-hspki_realm string
PKI realm (default "cluster.local")
-hspki_tls_ca_path string
Path to PKI CA certificate (default "pki/ca.pem")
-hspki_tls_certificate_path string
Path to PKI service certificate (default "pki/service.pem")
-hspki_tls_key_path string
Path to PKI service private key (default "pki/service-key.pem")
These should be set accordingly in your development environment.