security-api-gateway only supports reading vault token format not root token format

[anonymouse64]

The current token reading that edgexproxy performs assumes the basic structure of a token as returned from vault when creating a token and isn't compatible with specifying a root token format. I.e. on my machine this is what the resp-init.json (root token) looks like:

{
  "keys": [
    "abcdef",
    "abcdef",
    "abcdef",
    "abcdef",
    "abcdef"
  ],
  "keys_base64": [
    "abcdef",
    "abcdef",
    "abcdef",
    "abcdef",
    "abcdef"
  ],
  "root_token": "s.abcdef"
}

while the kong-token.json (kong specific token) looks like this:

{
  "request_id": "uuid",
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": null,
  "wrap_info": null,
  "warnings": null,
  "auth": {
    "client_token": "s.abcdef",
    "accessor": "abcdef",
    "policies": [
      "default",
      "kong"
    ],
    "token_policies": [
      "default",
      "kong"
    ],
    "metadata": null,
    "lease_duration": 604800,
    "renewable": true,
    "entity_id": "",
    "token_type": "service"
  }
}

and the code for importing the token specified in the configuration.toml file (under the toml key secretservice.tokenpath) only looks for the .auth and then the client_token keys in the json file, hence assumes a specific token format and is unable to use the root-token format from resp-init.json.

If we want to be able to use the root token with edgexproxy we either would need to reorganize the token format of resp-init.json to be in line with the current token format, or we would need to write go code which would be able to read both the root token format and this other token format.

[tingyuz]

This was due to the roll back on the secret store as it was decided to use the root token at late stage of Edinburgh release. We need to make both components consistent. To change it back to client_token we need to resolve the issue of token expiration and renew on secret store. This is an ongoing effort currently.

[anonymouse64]

@jim-wang-intel does your pki-init program recently proposed fix this issue? I don't think it would, but perhaps your program generates and stores a root token for vault in a format that edgexproxy here (soon to be renamed as security-proxy-setup) can read without additional changes to edgexproxy

[jim-wang-intel]

@jim-wang-intel does your pki-init program recently proposed fix this issue? I don't think it would, but perhaps your program generates and stores a root token for vault in a format that edgexproxy here (soon to be renamed as security-proxy-setup) can read without additional changes to edgexproxy

@anonymouse64 Ian, No, currently, the pki-init application generates / caches the TLS material like certificates and no token involved yet. The reading of vault tokens will rely on the security-service with token/vault worker as seen in the vault-init and unsealing in this diagram from @bnevis-i Bryon's High Level Desing (HLD). https://github.com/bnevis-i/security-secret-store/blob/bnevis/threat-model-2/doc/threat-model/high_level_design.md#vault-initialization-and-unsealing-flow . So that is future step and should be in another components or the modification version of vault-worker. Bryon, please chime in if you have additional thoughts.

[bnevis-i]

To change it back to client_token we need to resolve the issue of token expiration and renew on secret store. This is an ongoing effort currently.

I would like more information on this. It seems to me that the current logic in cmd/vaultworker/main.go will always recreate the admin and kong client tokens which means it should be valid and current (barring race conditions of reading tokens from a previous run) by the time that it is needed to install the Kong proxy cert. In fact, I think there is a token leaking bug here, as these tokens are stored in the vault database and continue to exist until they are explicitly deleted. Moreover, go-mod-core-security should be responsible for refreshing tokens as needed. Furthermore I think that instead of saving the entire json response when creating vault tokens we should only preserve { "auth": { "client_token": "xxx", "accessor": "xxx", } } and not any other fields (and go-mod-core-security should only look for auth: client_token).

My intention is to remove the token generating code that is inline in cmd/vaultworker/main.go and replace it with a "token server" (as a co-component in the worker microservice) that generates tokens for every microservice. The token server will expect that the vault master key is available and use that to generate a token-issuing-token for itself and then drop its privileges prior to generating those tokens. The root token itself would be revoked as recommended by the Vault hardening guidelines as it is only needed for unsealing the vault and bootstrapping the token server.