Proof of Concept TDP Based Kibana Auth

[elipe17]

Summary of Changes

• Added routes to browse to Kibana from the frontend
• Added a very generic/simple authentication check view to backend to redirect to Kibana if user has correct permissions.
  Pull request closes Spike: Secure OFA staff access to Kibana #1858

Considerations

• Implementing auth in this manner prevents us from leveraging Elastic/Kibana RBAC. All users who can access Kibana will be able to read/write any index in Elastic. In the future, if we wanted granular RBAC, we will need to write our own plugin for Elastic to integrate our auth with their realm model. Maybe there are open source options that exist for this? We could also theoretically make direct requests to the Elastic server security API to try and hack RBAC by creating the user/group in realtime when we authenticate from the backend.
• When deployed, we will need to deny any external incoming traffic on the port we deploy the Elastic/Kibana server on to prevent users from stepping around TDP auth and accessing Elastic/Kibana directly. Maybe there is also a way to do this with NGINX if all traffic is routed through that.
• Is there a way we can get around the redirect/hide the Kibana URL and make it seem TPD native?

How to Test

List the steps to test the PR
These steps are generic, please adjust as necessary.

cd tdrs-frontend && docker-compose up --build
cd tdrs-backend && docker-compose up --build

• Open http://localhost:3000.
• Browse to /kibana before logging in and verify that you cannot see Kibana/stay at the login page
• Sign in as an admin/data analyst/developer user
• Browse to /kibana or click the navbar item. Verify that you still cant see kibana because you did not authenticate with hhs ams.
• Add BYPASS_KIBANA_AUTH="yes" to your backend .env file, browse to /kibana and verify you can see the Kibana home page.

Deliverables

More details on how deliverables herein are assessed included here.

Deliverable 1: Accepted Features

Checklist of ACs:

• Dev-ready requirements for As an OFA staff member, I want to be able to access Kibana from TDP #1350 and potential follow-on tickets
• Recommended cloudfoundry security guidelines and configurations
• TDP user logic and flows for authorization
• Kibana/ES permissions and configurations guidelines/recommendations
• Application security hardening both for Kibana/ES and TDP
• Investigate/automate security scans around our data pool
• Testing Checklist has been run and all tests pass
• README is updated, if necessary

Deliverable 2: Tested Code

• Are all areas of code introduced in this PR meaningfully tested?
  • If this PR introduces backend code changes, are they meaningfully tested?
  • If this PR introduces frontend code changes, are they meaningfully tested?
• Are code coverage minimums met?
  • Frontend coverage: [insert coverage %] (see CodeCov Report comment in PR)
  • Backend coverage: [insert coverage %] (see CodeCov Report comment in PR)

Deliverable 3: Properly Styled Code

• Are backend code style checks passing on CircleCI?
• Are frontend code style checks passing on CircleCI?
• Are code maintainability principles being followed?

Deliverable 4: Accessible

• Does this PR complete the epic?
• Are links included to any other gov-approved PRs associated with epic?
• Does PR include documentation for Raft's a11y review?
• Did automated and manual testing with iamjolly and ttran-hub using Accessibility Insights reveal any errors introduced in this PR?

Deliverable 5: Deployed

• Was the code successfully deployed via automated CircleCI process to development on Cloud.gov?

Deliverable 6: Documented

• Does this PR provide background for why coding decisions were made?
• If this PR introduces backend code, is that code easy to understand and sufficiently documented, both inline and overall?
• If this PR introduces frontend code, is that code easy to understand and sufficiently documented, both inline and overall?
• If this PR introduces dependencies, are their licenses documented?
• Can reviewer explain and take ownership of these elements presented in this code review?

Deliverable 7: Secure

• Does the OWASP Scan pass on CircleCI?
• Do manual code review and manual testing detect any new security issues?
• If new issues detected, is investigation and/or remediation plan documented?

Deliverable 8: User Research

Research product(s) clearly articulate(s):

• the purpose of the research
• methods used to conduct the research
• who participated in the research
• what was tested and how
• impact of research on TDP
• (if applicable) final design mockups produced for TDP development

[elipe17]

A note for @ADPennington, deploying this to QASP will not deploy kibana. You will only be able to test this proof of concept locally. The full deployment of kibana will be available in this PR.

[ADPennington]

@elipe17 given this:

All users who can access Kibana will be able to read/write any index in Elastic.

we want to lock this down to sys admin role, as this seems like privileged access.

I'm also now wondering what this permission group will have access to in the way of parsed data:

• Might there be a feasible way for sys admins to pass parsed data to members of this less privileged group?
• I also thought we might have some queries pre-built in Kibana that would enable users with access to it to quickly generate extracts (e.g. .csv or .json format) of parsed data (e.g. all T1 records for FY2024, Q1), which might help mitigate risks of changing anything in the db.

I'm mostly thinking aloud here...maybe we have to get creative given the limitations of working with this wrapper.

[elipe17]

Updating so that OFA System Admin are the only users who can access Kibana. Until we get more control over our cloud resources Kibana's access is all or nothing. Users who can access admin will have admin privileges in Kibana. However, if the users delete data/documents/indices in Kibana, that will not affect Postgres and no data will be truly lost. We can recover the data in Elastic/Kibana by rebuilding the search indices with elastic_search_dsl manage.py command.

Tickets will be written to have pre-canned dashboards and queries so that Kibana is just ready when deployed versus having to do manual configuration.

[ADPennington]

thanks for adding the kibana tab to the sitemap :) cc: @ttran-hub

[ADPennington]

great work @elipe17 🚀

• verified that only developer and sys admin roles can see the kibana tab and a kibana tab in site map
• kibana endpoint is accessible when bypass = "yes"; else it redirects to frontend

My testing notes are saved here: https://hackmd.io/ro2G3T9yTF-w31gAbeXWlQ?view

[jtimpe]

@ADPennington are we able to merge this now or is there something blocking? cc @andrew-jameson

[ADPennington]

@ADPennington are we able to merge this now or is there something blocking? cc @andrew-jameson

I defer to @andrew-jameson. i approved this. is it needed for local development?

[andrew-jameson]

@ADPennington are we able to merge this now or is there something blocking? cc @andrew-jameson

I defer to @andrew-jameson. i approved this. is it needed for local development?

Ok, I recall we wanted to pause this pending the pen test results and deployment related issues. Since we're moving ahead on Kibana, I'll merge this and #2805 will follow soon pending QASP review.