Implement Tezos node RPC access via secret link about tezos-k8s HOT 1 CLOSED

@itkach @harryttd these specifications require adding more persistent storage into the infra. I see in PR#36 that the current implementation uses redis for this purpose.

Maybe we can do without?

People need to prove their ownership of a tz address as part of the auth flow, because this address contains tokens - either assigned at genesis or transfered by the private chain operator.

Here is a workflow that would (I think) eliminate the need for redis by using the chain itself as persistent storage:

Workflow to receive secret URL:

• Client initiates the conversation:

  curl -X POST https://vending-machine/$CHAIN_ID

  Note that vending machine URL itself is a secret link emebedding chain id that needs to be shared with the client.

• Vending machine responds with a GUID, e.g.

  63a2096b01774122807a44e7695e5a9f

  This GUID serves as both conversation identifier and nonce that will
  be used to confirm ownership of a tz address

• Client signs the guid and posts the guid, signature and public key

  TZ_ALIAS=key20200625
  GUID=63a2096b01774122807a44e7695e5a9f
  SIGNATURE=$(tezos-client -p PsCARTHAGazK sign bytes 0x05${GUID} for ${TZ_ALIAS} | cut -f 2 -d " ")
  PUBLIC_KEY=$(tezos-client show address ${TZ_ALIAS} 2>/dev/null | grep "Public Key:" | cut -d: -f2)
  curl -X POST -d "guid=${GUID}" -d "signature=${SIGNATURE}" -d "${PUBLIC_KEY}"  https://vending-machine

• Vending machine

  • validates signature
  • if signature is not valid returns error, otherwise
  • calculates tz address by hashing the public key
  • verifies that balance associated with the public key is not zero, returns error otherwise
  • generates predictable access token based on public key: ACCESS_TOKEN=HASH(PUBLIC_KEY,CHAIN_SECRET). CHAIN_SECRET is a unique, predictable string associated with the private chain, generated at chain inception.
  • derives Tezos node RPC URL with the access token embedded, e.g.
    https://tezos-node-rpc/{PUBLIC_KEY}_{ACCESS_TOKEN}
  • returns the URL to the client

• Client uses provided secret URL to access Tezos node RPC, e.g.
  tezos-client --endpoint=${SECRET_URL} (with tezos 8.0)

• RPC server:

  • verifies that ACCESS_TOKEN=HASH(PUBLIC_KEY,CHAIN_SECRET), returns error otherwise
  • puts the endpoint in RAM so all subsequent requests are whitelisted

To make secret URL shorter, one could also consider using a substring of public key.

Then you basically permission people by sending tokens to what they claim is their address. You could also build a faucet on top of that (any pubkey works, and the vending machine sends tokens to the key as part of the handshake).

Edit after offline discussion with Igor, problems are:

• does not address read-only rpc access
• non-revokability of SECRET_TOKEN
• conflates chain access and rpc access which is different
• on-chain storage not being suitable or appropriate for generic storage

from tezos-k8s.