Create cloudelastic-root group and add discovery members to this new group
Description
Description
Details
Details
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| admin: create new system groups for cloudelastic nodes | operations/puppet | production | +5 -0 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Unknown Object (Task) | |||||
| Resolved | • Mathew.onipe | T194186 rack/setup/install cloudelastic100[1-4].eqiad.wmnet systems | |||
| Declined | Feature | None | T71489 Expose mwgrep functionality on-wiki | ||
| Resolved | None | T109715 Replicate production elasticsearch indices to labs | |||
| Resolved | • Mathew.onipe | T214921 Setup elasticsearch on cloudelastic100[1-4] | |||
| Resolved | • debt | T214922 Create cloudelastic-root group |
Event Timeline
Comment Actions
Change 487040 had a related patch set uploaded (by Mathew.onipe; owner: Mathew.onipe):
[operations/puppet@production] admin: create new system groups for cloudelastic nodes
Comment Actions
Hi @Joe
cloudelastic is a replica of cirrussearch like labsdb* is to maps*. So this group separates access to cloudelastic and our main search cluster. This will allow access to members of the cloud platform team who should not access search cluster
Comment Actions
Related rights groups are wmcs-roots and wmcs-admin. Those 2 groups grant broader rights across Cloud Services bare metal instances (OpenStack servers, Wiki Replica databases). Keeping the rights for these cloud replicas separate from the rights for the production cirrussearch elasticsearch hosts is a good practice for cross-purpose limiting rights escalation issues.
Comment Actions
It was in the SRE meeting and there were no objections (SRE-2019-02-11#Access_Requests)
Comment Actions
Change 487040 merged by Gehel:
[operations/puppet@production] admin: create new system groups for cloudelastic nodes