How to use the Vault CLI tool with Teleport Application Access

[pschisa]

Hashicorp Vault is a secure secrets manager that offers a CLI tool for interacting with the Vault application. Here is how you can continue to utilize the Vault CLI tool when Vault is secured behind Teleport Application Access (on-prem or cloud).

Before you begin: Make sure you have already deployed/unsealed the Vault application, you have credentials to access Vault, and have downloaded the Vault CLI tool to your local machine

1. Configure Vault as a Teleport application and verify that it is accessible via the Teleport Web UI. Please follow the Application Access installation instructions provided on our website: https://goteleport.com/docs/application-access/guides/connecting-apps/.

2. Log in to the Teleport proxy using tsh login --proxy=<proxy-URL>. After a successful login, you should now be able to view your configured Vault application using the command tsh apps ls.

3. Log in to the application with tsh apps login <vault-app-name>. If successful, you should see output indicating you logged in successfully and an example curl command. The example curl command shows the CA cert, Cert, and Key file locations along with the Vault application public URL through Teleport. We will use the full URL (including https://), cert file path, and key file path (not the cacert) in the next step. Once logged in to an application, you can always review this information with the command tsh apps config.

4. Export the following necessary Vault CLI environmental variables on your local machine using the information obtained during login
   export VAULT_ADDR=https://<Teleport-Vault-App-URL>
export VAULT_CLIENT_CERT=<Cert-File-Path-From-App-Config>
export VAULT_CLIENT_KEY=<Key-File-Path-From-App-Config>

5. After exporting the variables, you should now be able to issue vault login successfully to begin Vault authentication and then execute Vault commands.

Example work flow:

#tsh login --proxy=schisa.teleport.sh --auth=Gitlab
If browser window does not open automatically, open it by clicking on the link:
 http://127.0.0.1:53775/a6ac7883-6b59-4fa4-b7d9-5fe99ac67132
> Profile URL:        https://schisa.teleport.sh:443
  Logged in as:       paul.schisa
  Cluster:            schisa.teleport.sh
  Roles:              admin
  Logins:             root
  Kubernetes:         enabled
  Kubernetes cluster: "canada-kate-cloud"
  Kubernetes groups:  system:masters
  Valid until:        2021-05-14 22:23:00 -0400 EDT [valid for 12h0m0s]
  Extensions:         permit-agent-forwarding, permit-port-forwarding, permit-pty

#tsh apps ls
Application Description Public Address            Labels
----------- ----------- ------------------------- -------------
vault                   vault.schisa.teleport.sh  region=canada
dumper                  dumper.schisa.teleport.sh

#tsh apps login vault
Logged into app vault. Example curl command:

curl \
  --cacert /Users/paulschisa/.tsh/keys/schisa.teleport.sh/certs.pem \
  --cert /Users/paulschisa/.tsh/keys/schisa.teleport.sh/paul.schisa-app/schisa.teleport.sh/vault-x509.pem \
  --key /Users/paulschisa/.tsh/keys/schisa.teleport.sh/paul.schisa \
  https://vault.schisa.teleport.sh:443

#tsh apps config
Name:      vault
URI:       https://vault.schisa.teleport.sh:443
CA:        /Users/paulschisa/.tsh/keys/schisa.teleport.sh/certs.pem
Cert:      /Users/paulschisa/.tsh/keys/schisa.teleport.sh/paul.schisa-app/schisa.teleport.sh/vault-x509.pem
Key:       /Users/paulschisa/.tsh/keys/schisa.teleport.sh/paul.schisa

#export VAULT_ADDR=https://vault.schisa.teleport.sh:443
#export VAULT_CLIENT_CERT=/Users/paulschisa/.tsh/keys/schisa.teleport.sh/paul.schisa-app/schisa.teleport.sh/vault-x509.pem
#export VAULT_CLIENT_KEY=/Users/paulschisa/.tsh/keys/schisa.teleport.sh/paul.schisa

#vault login
Token (will be hidden):
Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.

Key                  Value
---                  -----
token                <Redacted>
token_accessor       <Redacted>
token_duration       ∞
token_renewable      false
token_policies       ["root"]
identity_policies    []
policies             ["root"]

#vault secrets list
Path          Type         Accessor              Description
----          ----         --------              -----------
cubbyhole/    cubbyhole    cubbyhole_a440513e    per-token private secret storage
identity/     identity     identity_92d62087     identity store
sys/          system       system_0b6d3802       system endpoints used for control, policy and debugging

[waleed-cariad]

@pschisa Is there a way to restrict access to Vault based on which actions/commands a user is allowed to do to a specific vault server via vault-cli (given vault is secured by teleport as you described above)?

[pschisa]

@waleed-cariad Not today. Teleport application access is driven off the RBAC label system, which can granularly restrict access to various apps but we do not restrict the actions a user can take in the app through Teleport. However, Teleport can serve as a SAML IDP or pass headers/JWT tokens to the application to automatically authenticate the user to an appropriate account, which the application would then restrict.

I have not tested this with Vault specifically though

[waleed-cariad]

@pschisa
Another thing I would like to clarify is the session recording

Just to first add how we have configured vault access via teleport:

• we have our teleport cluster (auth & proxy) running on a kubernetes cluster with proxy service available on a public Domain Name/IP
• separately, in another kubernetes cluster, we have vault server running AND we have deployed a VM in the same VNET where the kubernetes cluster for vault is hosted. This VM, in our case, can be considered as teleport-agent. On this VM, we have deployed teleport configured with:
  • azure discovery service (to automatically discover and register vault's kubernetes cluster)
  • kubernetes service (to proxy connection to the kubernetes cluster registered by discovery service)
  • app service for our vault server

The teleport config file for this so called agent looks somethng like this

version: v3
teleport:
  data_dir: /opt/teleport-agent
  join_params:
    method: azure
    token_name: azure-token-for-agents
  proxy_server: teleport.example.com:443
auth_service:
  enabled: off
proxy_service:
  enabled: off
ssh_service:
  enabled: off
discovery_service:
  enabled: on
  discovery_group: prod
  azure:
    - types: ["aks"]
      regions:
        - <azure-region>
      resource_groups:
        - <aks-resource-group>
      tags:
        TeleportKubernetesName:
          - vault-demo-cn
kubernetes_service:
  enabled: on
  resources:
    - labels:
        TeleportKubernetesName:
          - vault-demo-cn
app_service:
  enabled: on
  apps:
    - name: vault-demo-cn
      uri: https://10.0.0.1:8200

in app_service, uri is an internal ip where vault server is exposed and it's accessible from this VM where this teleport-agent is running.

We do not want to expose this app service on a Public Endpoint as teleport will normally do by exposing it as vault-demo-cn.teleport.example.com rather what we are doing is:

#tsh login  --proxy=teleport.example.com
#tsh proxy vault-demo-cn --port 8200
  - returns --> Proxying connections to vault-demo-cn on 127.0.0.1:8200
#export VAULT_ADDR=http://localhost:8200 (as we have opened the proxy above to our prod-vault-app on 8080)
#vault login
#vault secrets list

This works fine for us BUT we are expecting the session to be recorded as we have opened a proxy session to this app vault-demo-cn and we also see the following in our audit logs on the web ui

and this session uploaded info also

But there are no recordings appearing under Session Recordings tab on the UI. Our goal here is to either get the session recorded for any user who access this vault server via vault-demo-cn teleport app or at-least get all the logs audited for each command executed against the vault server after opening up a proxy to vault-demo-cn app and apparently none of them seems to be appearing in our current setup.

Could you please advise !!!

[stevenGravy]

Teleport captures a stream of app.session.request audit events related to application access. (1) These audit events are bucketed into 5-minute time intervals informally referred to as "chunks." App sessions

For application access sessions, Teleport records the following:

• A stream of app.session.request audit events related to application access - The audit events are grouped into 5-minute intervals called "chunks" It's important to note that unlike SSH or Kubernetes sessions, Teleport does not capture the entire screen output for application sessions. Instead, it focuses on recording the HTTP requests made during the session.

It's not possible to get a console or web browser recording of application sessions, but you can see all the HTTP requests made by the user For more detailed information about application access and its capabilities, you may want to refer to the Teleport documentation or ask more specific questions about particular aspects of application session recording.

You can see the content with tsh play --format=json <chunksessionid>