Page MenuHomePhabricator

Requesting access to analytics-privatedata-users and wmf LDAP for fkaelin
Closed, ResolvedPublicRequest

Description

Requestor provided information and prerequisites

This section is to be completed by the individual requesting access.

  • Wikitech username:Fabian Kaelin
  • Preferred shell username:fab
  • Email address:fkaelin@wikimedia.org
  • Ssh public key (must be dedicated key for wmf production):ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHyKPeAQbIJzDPFnjM4i0gl4RbDUZRJB7aPhzTwtjpAH fab@wmf
  • Requested group membership: analytics-privatedata-users
  • Reason for access:wmf employee, research engineer
  • Name of approving party (hiring manager for WMF staff):Leila Zia
  • Requestor -- Please Acknowledge that you have read and signed the L3 Wikimedia Server Access Responsibilities document: Yes
  • Requestor -- Please coordinate obtaining a comment of approval on this task from the approving party.

SRE Clinic Duty Confirmation Checklist for Access Requests

This checklist should be used on all access requests to ensure that all steps are covered, including expansion to existing access. Please double check the step has been completed before checking it off.

This section is to be confirmed and completed by a member of the SRE team.

  • - User has signed the L3 Acknowledgement of Wikimedia Server Access Responsibilities Document.
  • - User has a valid NDA on file with WMF legal. (This can be checked by Operations via the NDA tracking sheet & is included in all WMF Staff/Contractor hiring.)
  • - User has provided the following: wikitech username, preferred shell username, email address, and full reasoning for access (including what commands and/or tasks they expect to perform)
  • - User has provided a public SSH key. This ssh key pair should only be used for WMF cluster access, and not share with any other service (this includes not sharing with WMCS access, no shared keys.)
  • - access request (or expansion) has sign off of WMF sponsor/manager (sponser for volunteers, manager for wmf staff)
  • - non-staff requests: 3 business day wait must pass with no objections being noted on the task
  • - Patchset for access request
  • - Fabian Kaelin added to the wmf LDAP group

For additional details regarding access request requirements, please see https://wikitech.wikimedia.org/wiki/Requesting_shell_access

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

@Ottomata and @leila, I think your approvals are needed for this review, thank you!

(omg! one of your first phab tasks!:)

Approved.

jijiki triaged this task as Medium priority.Nov 13 2020, 12:07 PM

Fabian will also need analyitcs-privatedata-users. I edited the task description to say so.

Approved!

Thanks. I did create a separate task for the analytics-privatedata-users group, which seemingly wasn't necessary. https://phabricator.wikimedia.org/T267816

AH! yeah one ticket is fine. I'll close that as a duplicate.

Ottomata renamed this task from Requesting access to researchers for fkaelin to Requesting access to researchers, analytics-privatedata-users and wmf LDAP for fkaelin.Nov 16 2020, 2:19 PM
herron updated the task description. (Show Details)

Change 641241 had a related patch set uploaded (by Herron; owner: Herron):
[operations/puppet@production] admin: add Fabian Kaelin 'fab' account, and group memberships

https://gerrit.wikimedia.org/r/641241

Fabian will also need analyitcs-privatedata-users. I edited the task description to say so.

There are comments in the code that say about "researchers": " If a user is added to this group it should not need to be in analytics-users or analytics-privatedata-users."

Is this not true here and a special case?

If the comments say that they are probably true. researchers is kinda outdated. Just analyitics-privatedata-users then.

herron renamed this task from Requesting access to researchers, analytics-privatedata-users and wmf LDAP for fkaelin to Requesting access to analytics-privatedata-users and wmf LDAP for fkaelin.Nov 17 2020, 5:18 PM
herron updated the task description. (Show Details)
herron subscribed.

If the comments say that they are probably true. researchers is kinda outdated. Just analyitics-privatedata-users then.

Ok thanks, I've updated the patch and task to reflect this.

Change 641241 merged by Herron:
[operations/puppet@production] admin: add Fabian Kaelin 'fab' account, and group memberships

https://gerrit.wikimedia.org/r/641241

herron claimed this task.

The requested shell and LDAP access has been granted, and will be fully active within 30 minutes. I'll transition this to closed now, but please re-open if any follow-up is needed. Thanks!

Thanks for the assistance! I am trying to connect, and key seems to have propagated but I see the following error

$ ssh -v bast1002.eqiad.wmnet
[snip]
debug1: Next authentication method: publickey
debug1: Offering public key: /home/fab/.ssh/wmf_prod ED25519 SHA256:iIFh8ZfJOewuqKKZgStkfmPejgsYEgZC0a9FutV860M explicit agent
debug1: Server accepts key: /home/fab/.ssh/wmf_prod ED25519 SHA256:iIFh8ZfJOewuqKKZgStkfmPejgsYEgZC0a9FutV860M explicit agent
debug1: Authentication succeeded (publickey).
Authenticated to bast1002.wikimedia.org ([208.80.154.86]:22).
debug1: channel_connect_stdio_fwd bast1002.eqiad.wmnet:22
debug1: channel 0: new [stdio-forward]
debug1: getpeername failed: Bad file descriptor
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
channel 0: open failed: administratively prohibited: open failed
stdio forwarding failed
kex_exchange_identification: Connection closed by remote host

My ssh config is pasted from wiki

# Turn this on for Match to work.
CanonicalizeHostname yes

# Defaults for all WMF hosts.
Match host=*.wikimedia.org,*.wmnet
    ForwardAgent no
    IdentitiesOnly yes
    KbdInteractiveAuthentication no
    PasswordAuthentication no
    User fab

# Configure the initial connection to the bastion host, with the one
# HostName closest to you
Host bast
    HostName bast1002.wikimedia.org
    IdentityFile ~/.ssh/wmf_prod

# Proxy all connections to internal servers through the bastion host
Host *.wmnet *.wikimedia.org !gerrit.wikimedia.org !bast*.wikimedia.org
    ProxyJump bast
    IdentityFile ~/.ssh/wmf_prod

@fkaelin Try ssh bast1002.wikimedia.org first. The bastion hosts have public IPs, so in .wikimedia.org instead of eqiad.wmnet. Once that works then try another host with a private IP in eqiad.wmnet that is behind that bastion host.

And since you have "Host *.wmnet *.wikimedia.org !gerrit.wikimedia.org !bast*.wikimedia.org" in your config it means that if the host starts with "bast" and ends in "wikimedia.org" it will NOT try to jump via the bastions as it does for hosts in the private .wmnet network behind it. Otherwise it would be a cycle where it tries to jump via bastion to get to a bastion.

@fkaelin I just saw you are currently also being added on IRC, feel free to ping me (nick: mutante) to talk about SSH access if you like.

Thanks for the explanation, it makes sense now.

I am trying to access Hue, and after looking at these tasks requesting access for Hue T271602 and T252703 I am not sure if there is a template task for requesting access? If I understand @elukey 's comment, there is a new'ish way to request UI credentials only, instead of the more involved ssh access. However, I would imagine that most people requesting ssh access will also end up using the UI, so would it make to sense to create the the UI based creds as part of this task as well?

I am trying to access Hue, and after looking at these tasks requesting access for Hue T271602 and T252703 I am not sure if there is a template task for requesting access? If I understand @elukey 's comment, there is a new'ish way to request UI credentials only, instead of the more involved ssh access. However, I would imagine that most people requesting ssh access will also end up using the UI, so would it make to sense to create the the UI based creds as part of this task as well?

Hue is sadly a special use case for us, since it requires a manual sync from LDAP as described in https://wikitech.wikimedia.org/wiki/Analytics/Cluster/Hue. We have a new version of hue (hue-next.wikimedia.org) that fully support user auto-creation etc.. (so this step wouldn't be needed) but it suffers from a lot of regression bugs (see T264896). I really hope to decommission the current/old Hue as soon as possible, but in the meantime we'll have to review case-by-case :(

Just added your user to Hue, you should be able to use it now!

@elukey, thanks for the background and for adding my user to Hue - I was able to login.