C

• we need the ability to write policies in HCL, with any level of complexity, and post those HCL policies to a vault server

T

• dude you just need to convert the policy to a string with quotes escaped, see below

A

• @see hashicorp/vault#18551
  • found a workaround but im sure theres a way to send valid hcl / json without having to parse it

creating policy policy_admin_vault:
path "secret/*" { # kv-v2
  capabilities = [ "create", "read", "update", "delete", "list", "patch", "sudo"]
}

path "env/*" { # kv-v1
  capabilities = [ "create", "read", "update", "delete", "list", "patch", "sudo"]
}

path "sys/*" {
  capabilities = [ "create", "read", "update", "delete", "list", "patch", "sudo" ]
}

path "auth/*" {
  capabilities = [ "create", "read", "update", "delete", "list", "patch", "sudo" ]
}

path "database/*" {
  capabilities = [ "create", "read", "update", "delete", "list", "patch", "sudo" ]
}

path "pki*" {
  capabilities = [ "create", "read", "update", "delete", "list", "patch", "sudo" ]
}


[DEBUG] SCRIPT.VAULT.SH
------------
[url]: https://dev.nirv.ai:8300/v1/sys/policies/acl/policy_admin_vault
[args]: -H X-Vault-Token: hvs.EqX-Bzh2cy5yb1lkcXlraHhYWmlLY1R5U2FxcTdoTWo --data {
    "policy": 
        "

                path \"secret/*\" {   
                        capabilities = [ \"create\", \"read\", \"update\", \"delete\", \"list\", \"patch\", \"sudo\"]
                }
                path \"env/*\" {  
                        capabilities = [ \"create\", \"read\", \"update\", \"delete\", \"list\", \"patch\", \"sudo\"]
                }
                path \"sys/*\" {  
                        capabilities = [ \"create\", \"read\", \"update\", \"delete\", \"list\", \"patch\", \"sudo\" ]
                }
                path \"auth/*\" {  
                        capabilities = [ \"create\", \"read\", \"update\", \"delete\", \"list\", \"patch\", \"sudo\" ]
                }
                path \"database/*\" {  
                        capabilities = [ \"create\", \"read\", \"update\", \"delete\", \"list\", \"patch\", \"sudo\" ]
                }
                path \"pki*\" {  
                        capabilities = [ \"create\", \"read\", \"update\", \"delete\", \"list\", \"patch\", \"sudo\" ]
                }
        "
    }
------------

C

• nirvai scripts should be executable from any dir, as the use case is beginning to expand beyond a single app/package

T

A

use jq 'split(",")'

• refactor nirvai scripts into nim binary
• check how choosenim does platform detection

• start : nmd poop & & doesnt work with sudo, sudo -b poop works fine

microsoft/vscode#172237

export REG_CERTS_PATH=apps/nirvai-core-letsencrypt/dev-nirv-ai
export REG_DOMAIN=nirv.ai
export REG_SUBD=dev

domain & subd should default be extracted from the letsencrypt REG_CERTS_PATH
then consumers dont have to supply the domain or subdomain

C

• complete the integration with vault http endpoints consumed by nirvai-core
• it should:
  -- be a dropin replacement for the vault cli for infrastructure services
  -- reference integration guide http services

T

A

if ! someFn; then doThisOtherThing

• see microsoft/vscode#169656

they can now be added to shell init script and run from anywhere

• @see hashicorp/vault#18555
• not getting any errors in script, just cant see it in the UI
• i presume its getting enabled because if I try to enable it again, it returns an error

"@level":"error",
"@message":"error occurred during enable mount",
"@module":"secrets.system.system_42197108",
"@timestamp":"2022-12-26T12:05:54.943134Z",
"error":"path is already in use at env/",
"path":"env/"

moving pretty fast and not following best practices

• ensure atleast set -eu at top
• no hardcoded values, vars et at top
• no logic embedded in case structs; call functions at top
• no multi level if statements: use case structs
• no hella long if else if, else if, else ifs, use case statements
• ensure help is provided if invalid input received
• add DEBUG=${NIRV_SCRIPT_DEBUG:-''} to all scripts to enable debugging via 1 env var (see script.vault.sh)
• update nirvai/docs/scripts readme.md
  • ensure interfaces are clearly stated
  • ensure all copypasta works
  • ensure basic workflow provided
• no bash, keep it posix compliant (there might be a ticket for this already)
• decompose into multiple files, e.g. they should all share the same base interface

• @see hashicorp/vault#18567

C

• decided to split integration with vault into two stages, ALPHA and BETA
  • lol it was taking longer than expected
• this is for beta, and only when these integrations are needed
  • likely once were' exiting test.nirv.ai and entering stage.nirv.ai

T

• admin token automation
  • secrets engines enablement and configuration
    • AWS
      • ALPHA: managing AWS access via aws cli ~/.aws/configs and ~/.aws//credential files
      • BETA: manage AWS creds via dynamic provisioning with vault
    • nomad
      • ALPHA: anyone with access to server can submit jobs
      • BETA: setup nomad ACL policies and integrate with vault
    • ssh
      • ALPHA: managing ssh via ~/.ssh/config and storing keys locally
      • BETA: manage ssh creds via vault provisioning
    • terraform cloud
      • ALPHA: logging into tf cloud via github; and only using it to store state (using CLI workflow)
      • BETA: generate tf cloud creds dynamically via tf cloud secret backend
  • auth schemes enablement and configuration
    • aws
      • ALPHA: authneticating to vault via approle, or token auth
      • PROD: not sure when this will be appropriate,but this enables authenticating to vault via IAM policies for humans or IAM policies attached to ec2 instances (machine authentication)
        • basically vault asks AWS to validate the request via IAM id/arn or something like that, spend some time on this when its relevant
    • userpass
      • there arent any users but me and my machines, fk userpass right now

A

• nomad acl docs
• securing nomad tutorials
• vault: nomad secrets engine
• vault: aws secrets engine
• vault ssh secrets engine
• vault: tf cloud secret backend
• vault: vault auth delegation to aws

scripts has reached a maturity level that requires protection

@see hashicorp/vault#18438

• @see hashicorp/vault#18550
• the token still gets created, so report the issue and move on
• im not even sure where the display_name is supposed to be viewed so ignore that too
  • haha display name is returned when you lookup the token, but not in the response