Page MenuHomePhabricator

Lock down tools-sgebastion-10 (login-buster.toolforge.org) to only members of tools with known dependencies on it
Closed, ResolvedPublic

Description

The Buster bastion (tools-sgebastion-10) largely exists because of a few select tools that we know have dependencies not yet met by the new slim bastions.

As we're close to fixing the known blockers for migrating off it, we should lock access to that bastion to only those tools, in order to find out about any other users or tools still using it to break now (and thus hopefully make themselves known) instead of only doing that when we think we're ready to shutdown the bastion.

The MOTD on login-buster has already been urging people to migrate away for a while.

Current list of known tools:

  • anomiebot

Event Timeline

taavi updated the task description. (Show Details)

Mentioned in SAL (#wikimedia-cloud) [2025-06-23T09:08:05Z] <taavi> restrict logging in to tools-sgebastion-10 (aka login-buster) T397459

taavi claimed this task.

Per the last WMCS team meeting, I've set profile::ldap::client::labs::restricted_to in the tools-sgebastion prefix hiera to implement this.

Per the last WMCS team meeting, I've set profile::ldap::client::labs::restricted_to in the tools-sgebastion prefix hiera to implement this.

Per https://gerrit.wikimedia.org/r/plugins/gitiles/cloud/instance-puppet/+/2fd31765a8aef45313bdd02a2ebc86cf3de0b885

diff --git a/tools/tools-sgebastion.yaml b/tools/tools-sgebastion.yaml
index 8244274..b572e9b 100644
--- a/tools/tools-sgebastion.yaml
+++ b/tools/tools-sgebastion.yaml

@@ -4,6 +4,9 @@
 login_server: true
 mount_nfs: true
 profile::ldap::client::labs::client_stack: sssd
+profile::ldap::client::labs::restricted_to:
+- tools.admin
+- tools.anomiebot
 profile::wmcs::nfsclient::nfs_version: '4'
 prometheus::node_exporter::collectors_extra:
 - mountstats

Only Developer accounts that are also a member of one of these tool service groups should be able to login to the tools-sgebastion-10.tools.eqiad1.wikimedia.cloud in the future.

I see that @-jem- is currently logged in on tools-sgebastion-10.tools.eqiad1.wikimedia.cloud, but it looks like their sessions predate the 2025-06-23 config change.

Thanks for the ping. I'm migrating my automatic tasks that require direct shell access to PHP (only available in login-buster, unfortunately). I think everything important is working now, but I intend to stay logged in, just in case it's still useful. Anyway, feel free to kick me/restart/shutdown the system when needed.

Thanks for the ping. I'm migrating my automatic tasks that require direct shell access to PHP (only available in login-buster, unfortunately). I think everything important is working now, but I intend to stay logged in, just in case it's still useful. Anyway, feel free to kick me/restart/shutdown the system when needed.

Depending on what your automation needs to do, you may be able to run your actions using webservice shell. This stuff is probably not documented well, but you can pass a command to run as the tool user to become and you can also pass a command to run inside a container to webservice shell. Putting these together can do some neat things:

bd808@mbp03:~/projects/wmf$ ssh login.toolforge.org -- become bd808-test -- webservice php8.2 shell -- php --version
PHP 8.2.18 (cli) (built: Apr 11 2024 22:07:45) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.18, Copyright (c) Zend Technologies
    with Zend OPcache v8.2.18, Copyright (c), by Zend Technologies
bd808@mbp03:~/projects/wmf$ $ ssh login.toolforge.org -- become bd808-test -- "webservice php8.2 shell -- /bin/bash -c 'pwd && ls -d */ && cd public_html && pwd && ls'"
/data/project/bd808-test
bug-54647/  node-k8s-email-test/  toollabs/      venv-keystone2-py3/  www/
logs/       public_html/          venv-k8s-py3/  venv-keystone-py3/
/data/project/bd808-test/public_html
admin                 index.html   si.php      versions.php
community-norms-talk  precise.php  sn.php      wikitech-animated.svg
elastic7.php          pycgi.py     upload.php  wikitech-logo.html
elastic.php           robots.txt   venv.py2

Thanks, @bd808. Months ago, I had two or three conversations about my situation in IRC, but I think this idea never came up (I knew about creating shell containers, but I only could use them interactively). I'm already using this.