アクセスリクエスト(AR)に関するよくある質問
サポートが必要ですか?
- 特定の SLA はありませんが、Issue で
@gitlab-com/business-technology/end-user-servicesに @メンションしてください。 - リクエストが緊急の場合は、Slack の Compass アプリ(上部の検索バーに「Compass」と入力して見つけます)または [email protected] を通じて IT に連絡してください。
アクセスが必要です
AR リクエストをしばらく開いたままにしています。対応を進めるにはどうすればよいですか?
- アクセスリクエストが手順に従って完了していること、およびアクセスが必要なシステム/ボルト/グループ/プロジェクトと、必要なロールまたは権限を含めたことを確認してください。
- ほとんどのアクセスリクエストには Manager の承認が必要です。AR で Manager をタグ付けし、Issue に ~“AR-Approval::Manager Approved” と ~“ReadyForProvisioning” のラベルを追加するよう依頼してください。
- アクセスをリクエストしているツールに対して、正しいプロビジョニング担当者を Issue にタグ付けし、担当に割り当てたことを確認してください。すべてのツールのプロビジョニング担当者は Tech Stackで確認できます。
- プロビジョニング担当者が IT チームの場合は、AR に ~“IT::to do” ラベルを追加してください。
- 上記のすべての手順を実行してもアクセスリクエストの対応が進まない場合は、ツールを所有するチームの Slack チャンネルで連絡してください。各チームの Slack チャンネルは Tech Stackで確認できます。
システムまたはグループ/ボルトへのアクセスが必要ですか?
- ニーズに基づいてテンプレートを選択してください。ほとんどの人は Bulk または Single Person テンプレートを使用します。
- オンボーディング中に漏れた場合を除き、ベースライン権限の一部であるものについてアクセスリクエストを作成しないでください。
- 次の場合を除き、Issue には
AR-Approval::Manager Approvedラベルが必要です。- Google Workspace のメールエイリアスまたはグループに追加される内部チームメンバー
- Slack グループに追加される内部チームメンバー
- まったく変更のないロールベースのベースライン権限
- システムへのアクセスをプロビジョニングする担当者に Issue を割り当ててください。
- サポートが必要な場合は、支援が必要な Issue へのリンクを添えて Slack チャンネル #it-help で IT-Ops に依頼してください。
- 作業に必要な最小限のアクセスのみを要求してください。
Manager の承認は必要ですか? 場合によります
次の内容をリクエストする場合、Manager の承認は不要です。
- Google Workspace のメールエイリアスまたはグループに追加される内部チームメンバー(そのグループが Google Cloud Platform の権限を提供する場合を除く)
- Slack グループに追加される内部チームメンバー
- 自身のロールベース権限に含まれるもの
Rails またはデータベースの本番コンソール(grpd)へのアクセスが必要です
Teleport を使用して、一時的なアクセスを次のいずれかにリクエストしてください。 Rails コンソール または データベースコンソール。
version.gitlab.com へのアクセスが必要です
すでにアクセスできる可能性があります。dev アカウントがあるかテストしてください。
- dev アカウントが必要な場合は、Single Person Access Requestを作成してください。
- dev アカウントがある場合は、versionに移動し、GitLab でログインして、認証情報の使用を許可してください。
Zendesk に Light Agent としてアクセスする必要があります
Zendesk Light アクセスのアクセスリクエストを作成する必要はありません。メールでアクセスを取得する手順に従ってください。
メールエイリアスを追加するか、氏名を変更する必要があります
メールエイリアスの追加または氏名変更には、slack_googlegroup_1password AR テンプレートを使用してください。
リクエストできる内容や数に制限はありませんが、追加または変更について短い説明を記載してください。不適切と判断された場合、または運用の裁量により、一部のエイリアスリクエストが却下されることがあります。
このアプリケーションの自動化は Okta で行われますが、「真の」システムのプロビジョニングとプロビジョニング解除は、影響を受けるシステム内でアクセス変更リクエストを通じて手動で完了する必要があります。
古いアクセスリクエストをクローズする
アクセスリクエストはできるだけ早く(30 日以内に)完了することが期待されます。
30 日(作成時点)を経過したアクセスリクエストを自動的にクローズするパイプラインを設定しています。
これは古い AR を減らし、バックログを整理するためです。例外として、AR に AccessReview ラベルがある場合、そのラベルを持つ Issue はパイプラインで無視されます。
このパイプラインは、Issue が自動的にクローズされること、およびチームメンバーが
残っているタスクがある場合にすべきことを示すコメントを Issue に追加します。
現在、パイプラインは毎週金曜日の午後 09:30 に実行するよう設定されています。これは 30 日経過したすべてのアクセスリクエスト Issue をクローズします。
ご注意ください。これは AR 自動クローザーの最初のイテレーションです。私たちのチームは、これを洗練し改善するために取り組みます。
既存のアクセスを削除する必要があります
削除する必要があるアクセスと対象者を指定したアクセスリクエストを作成してください。
a1f3c26a)