pki | ||
proto | ||
.gitignore | ||
arista.proto | ||
grpc.go | ||
main.go | ||
pki.go | ||
README.md | ||
service.go |
Old Shitty Arista eAPI/Capi <-> gRPC proxy
Our Arista 7148S does not support gRPC/OpenConfig, so we have to make our own damn gRPC proxy.
The schema is supposed to be 1:1 mapped to the JSON-RPC EAPI. This is just a dumb proxy.
PKI Introduction
This project is a testing ground for the HSCloud PKI setup. Long story short, all gRPC is mutually authenticated via TLS (server & client certs).
All certs for mutual auth have the following CN/SAN format:
..
For example, if principal maps into a 'group' and job into a 'user':
arista-proxy-dcr01u23.prod.c.example.com
job = arista-proxy-dcr01u23 principal = cluster-management-prod realm = c.example.com
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 logical grouping of jobs. It can, but doesn't need to, group jobs by similar permissions.
The Job is any name that identifies uniquely (within the principal) a security endpoint that describes a single security policy for a gRPC endpoint.
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.
This maps nicely to the Kubernetes Cluster DNS format if you set realm
to svc.cluster.local
.
Then, principal
maps to a Kubernetes namespace, and job
maps into a Kubernetes service.
arista-proxy-dcr01u23.arista-prod.svc.cluster.local
job/service = arista-proxy-dcr01u23
principal/namespace = arista-prod
realm = svc.cluster.local
ACLs based on job/principal are yet to be implemented :).
PKI Certs for Development
In production, those certs will be automatigacally provided for you by automation. In development, you'll have to do the following:
cd pki
./gen.sh
This will generate:
pki/ca.pem
- CA certificatepki/client{,-key}.pem
- certificate and key fordeveloper.humans.svc.cluster.local
pki/service{,-key}.pem
- certificate and key fortest.arista-proxy.svc.cluster.local
You will have to setup an /etc/hosts alias to make test.arista-proxy.svc.cluster.local
resolve to your machine.
# cat /etc/hosts
...
127.0.0.1 test.arista-proxy.svc.cluster.local
...
You can then start arista-proxy
with default flags and talk to it via gRPC:
./arista-proxy
alias grpc-dev="grpc -cacert $(pwd)/pki/ca.pem -key $(pwd)/pki/client-key.pem -cert $(pwd)/pki/client.pem"
grpc-dev test.arista-proxy.svc.cluster.local:42000 proto.AristaProxy.ShowVersion
Debug Status Page
The debug_address
flag controls spawning an HTTP server useful for debugging. You can use it to inspect gRPC request and view general status information of the proxy.
Flags
./arista-proxy -help
Usage of ./arista-proxy:
-alsologtostderr
log to standard error as well as files
-arista_api string
Arista remote endpoint (default "http://admin:password@1.2.3.4:80/command-api")
-debug_address string
Debug HTTP listen address, or empty to disable (default "127.0.0.1:30000")
-listen_address string
gRPC listen address (default "127.0.0.1:30001")
-log_backtrace_at value
when logging hits line file:N, emit a stack trace
-log_dir string
If non-empty, write log files in this directory
-logtostderr
log to standard error instead of files
-pki_realm string
PKI realm (default "svc.cluster.local")
-stderrthreshold value
logs at or above this threshold go to stderr
-tls_ca_path string
Path to PKI CA certificate (default "pki/ca.pem")
-tls_certificate_path string
Path to PKI service certificate (default "pki/service.pem")
-tls_key_path string
Path to PKI service private key (default "pki/service-key.pem")
-v value
log level for V logs
-vmodule value
comma-separated list of pattern=N settings for file-filtered logging