Those sessions create an ephemeral Container configured identically to your App Containers, so they're convenient to access a management console, run ad-hoc jobs, etc.
However, keep in mind that these Containers are ephemeral in nature. Unlike regular Containers, they won't be restarted when they crash. Also, if your connection to Aptible Deploy drops, the remote Container will be terminated.
SSH sessions will time out after 7 days.
When you create a SSH session using
aptible ssh, you're logging in to an ephemeral container. You are not logging to one of your running app containers.
This means that running commands like
pswon't reflect what's actually running in your App Containers, and that files that exist in your App Containers will not be present in the ephemeral session.
If you have PHI (or, more broadly speaking, sensitive information) in your app or database, it's very likely that PHI will at some point leak in your SSH session logs.
So, make sure you have the appropriate agreements in place with your logging provider before sending your SSH logs there. For PHI, you'll need a BAA.
Logs from Ephemeral SSH Sessions can be routed to Log Drains (select this option when creating the Log Drain).
All the output from ephemeral containers is captured and routed to a Log Drain.
Note that for interactive sessions, Aptible Deploy allocates a TTY for your container, so your Log Drain will receive exactly what the end-user is seeing. This has two benefits:
- You see the user's input as well.
- If you’re prompting the user for a password using a safe password prompt that does not write back anything, nothing will be sent to the Log Drain either. That prevents you from leaking your passwords to your logging provider.
operation_id: The ID of the Operation that resulted in the creation of this Ephemeral Session.
operation_user_name: The name of the user that created the Operation.
operation_user_email: The email of the user that created the Operation.
For Log Drains that don't support embedding metadata (i.e. Syslog Log Drains), the ID of the Operation that created the session is included in the logs.
Updated about a month ago