AWS Access For Lighthouse Kibana Group
Hey guys! This document outlines the AWS access request for the Lighthouse Kibana Group, specifically for Matt Christianson. We'll dive into the details, covering everything from the desired access to the expiration date, ensuring a smooth onboarding process. Let's get started!
Introduction to the AWS Access Request
So, this request is all about getting the right AWS access in place for the Lighthouse Kibana Group. This is crucial for their work with API Gateway (Kong) as they transition to LHDI Production. We want to ensure they have the tools they need while adhering to all the necessary protocols and deadlines. This guide will walk you through the specifics of the request, including contact information, roles, and the exact type of access needed. The goal is to provide a clear and concise overview, making it easy for everyone involved to understand and act accordingly. This is particularly important for contractors like Matt, ensuring they are set up for success and can contribute effectively from day one. Proper AWS access is key to maintaining data security, operational efficiency, and regulatory compliance within the VA ecosystem. This request carefully considers all these aspects to create a secure and productive environment for the Lighthouse team.
We'll cover the essential aspects, ensuring the request is well-documented and meets all requirements. This includes the roles of the individuals involved, the purpose of the access, and the timeline. Transparency and clarity are paramount, ensuring all stakeholders are informed and aligned. Getting the correct access right the first time reduces potential delays and bottlenecks, keeping the project on track. By following the outlined steps, we can efficiently onboard the Lighthouse Kibana Group, enabling them to perform their duties effectively and securely.
Furthermore, this request includes provisions for the termination of access, aligning with contractual obligations and security best practices. We will discuss the need for a decommissioning stop-gap for Lighthouse Kibana access within the DSVA AWS environment, with all details and required documentation available. The focus is on a smooth transition and adherence to all VA guidelines. This process ensures that the Lighthouse team has the necessary access throughout their project lifecycle, from onboarding to the eventual termination of access.
Key Details and Contact Information
Alright, let's break down the key players and their roles. This section is all about the people involved and their responsibilities. It’s like a quick reference guide, so you know who's who and what they do. This ensures that everyone is on the same page and knows whom to contact for specific questions or concerns. Remember, clear communication is crucial for a smooth workflow and successful project execution.
- COR Name: Keith Riley (VEMSIS). Keith is our main point of contact for contractual matters. Reach out to him for any questions related to the contract or vendor oversight.
 - Vendor Onboarding Representative Name: Luciana Kelty. Luciana is the go-to person for vendor onboarding. She can help with any onboarding-related queries or assistance with the setup process. Contact her at luciana.kelty@va.gov.
 - Your Name: Matt Christianson is the individual requesting access. He's the main point of contact, ensuring all access requirements are met.
 - Your Email: matthew.christianson1@va.gov. This is Matt's primary email address for all communications related to this request.
 - Your Slack Member ID: N/A, as Matt is not a DSVA Slack user.
 - Team, Role, and Company of the target individual: Lighthouse. This specifies the team, role, and company affiliation of the individual requesting access.
 - Product Manager (PM) name and email: Michael Hobson, shaun.hobson@va.gov. Contact Michael for product-related queries and project management oversight.
 - Product Owner (PO) name and email: Dave Mazik, david.mazik@va.gov. Dave is the product owner, responsible for defining and prioritizing the product backlog.
 
These details are vital for a smooth process, ensuring everyone has the necessary information to perform their roles efficiently. Having this info readily available saves time and helps prevent any potential delays during the access grant process.
Desired AWS Access and Expiration
Now, let's drill down into the specifics of the AWS access that's being requested. This section clearly defines what the Lighthouse Kibana Group needs to do their job effectively. It's like outlining the tools and permissions necessary to operate within the AWS environment. Accurate access is essential for data security, and operational efficiency, so getting this right is super important.
- Desired AWS Access: API Gateway (Kong) moving to LHDI Production, targeting completion by. It is recommended to have 1-2 months from that before termination, due to the contract transition. This means the Lighthouse group will have full operational access to the API Gateway using Kong with the appropriate resources.
 - Access Expiration: 5/31/26. This is the date the access will automatically expire. It’s a critical piece of information. This also ensures that access is time-bound, adhering to the contract's terms and security best practices.
 
We need to ensure that the team has the necessary access throughout their project lifecycle, from onboarding to the eventual termination of access. Proper termination helps prevent unauthorized access and aligns with security best practices. This also includes the proper decommissioning of access at the end of the project or contract, as outlined in the request. The access end date is set to coincide with the contract's termination date, which ensures compliance with security policies and prevents any unauthorized access. This expiration date helps to maintain security and aligns with contractual requirements.
Verification and Additional Notes
Before we wrap things up, let's cover a couple of essential items. It's all about verifying that everything is in order and providing any extra details that might be important. This is like a final checklist to ensure everything runs smoothly. Let's make sure everything is in place for a successful outcome.
- E-QIP Transmittal Confirmation: N/A, check Lighthouse Roster please. This confirms the security clearance process. Instead of the E-QIP, the Lighthouse Roster should be checked for confirmation.
 - Additional Notes: Includes COR information (Keith Riley), Contract Onboarding Rep (Luciana Kelty), and the reason for the SOCKS proxy decommissioning stop-gap for Lighthouse Kibana access. This section provides additional context and clarifies any specific requirements. All essential information, contact details, and specifics related to the AWS access request are included here. For this, reference these resources:
- SOCKS proxy decommissioning details are found here: https://lighthouseva.slack.com/archives/C013VCQKSE7/p1758824749693649
 - Full list in Canvas is found here: https://lighthouseva.slack.com/docs/T9YV7KLUX/F09PUAHGFL3
 
 
User Verification and Roster Check
One of the most important things to do before granting access is to verify that the user is on the correct roster. This is for security, compliance, and to make sure everyone is properly documented. This ensures that the user is authorized to receive access and that all the necessary checks and balances are in place. This will help make sure that we're keeping the environment secure.
- Roster Verification Steps:
- Search for VFS team member in Atlas.
 - Or search for the user on the Platform Team Roster.
 - If the user is on a VFS team but not a team member in Atlas, add the 'NOT YET' label and instruct them to start the Platform orientation process.
 - If a user is on a Platform team but not on the Platform Team Roster in Confluence, add the 'NOT YET' label and instruct them to reach out to their Product Manager to be added.
 - Comment in this issue saying which roster the user is listed in.
 - :warning: Is production access being requested or extended? Be sure to communicate to the Tier 1 Team that they need to set a reminder for the access expiration :warning:
 
 
These steps are crucial for ensuring that the right people get the right access. Following this process helps to maintain security and compliance within the VA's AWS environment.
That's it, guys! This document should have you covered. If you need anything else, feel free to reach out to the contacts listed above. Thanks, and let's keep things moving smoothly! Remember to double-check everything, and you're good to go!