You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR introduces the authentication functionality to GMT.
Authentication serves following functional needs:
Restricting certain API routes or optimization features to only authenticated users
Allowing certain authentication tokens unlimited measurement minutes while as restricting others / public to have limited measurement minutes
Mapping certain runs to specific authentication tokens and thus allowing for longer data rentention
Mapping submitted runs, ci_measurements and PowerHog data to certain authentication tokens and thus creating CarbonDB overviews
Design considerations
GMT is designed to be a fully self-hostable and open source application. In many cases no authentication is needed for open source teams using thus.
By default GMT will install a "DEFAULT" user which however has access to all ressources, has no quotas or limits.
The authentication is designed to be transparent when not configured meaning that the frontend as well as the CLI interface will transparently inject the "DEFAULT" user whenever accessing ressources.
Only when the system is updated, new machines are added or the code is modified the authentication token ACLs must be altered.
This is the current data structure of the ACL
{
"api": {
"quotas": {}, # Empty object means no quotas are applied"routes": [
"/v1/carbondb/add",
"/v1/ci/measurement/add",
"/v1/software/add",
"/v1/hog/add",
"/v1/authentication/data"
]
},
"data": {
"ci_measurements": {
"retention": 2678400# 31 days
},
"hog_coalitions": {
"retention": 2678400# 31 days
},
"hog_measurements": {
"retention": 2678400# 31 days
},
"hog_tasks": {
"retention": 2678400# 31 days
},
"measurements": {
"retention": 2678400# 31 days
},
"runs": {
"retention": 2678400# 31 days
}
},
"jobs": {
"schedule_modes": [
"one-off",
"daily",
"weekly",
"commit",
"variance"
]
},
"machines": [ # List will be filled automatically with future script1
],
"measurements": {
"quotas": {}, # Empty object means no quotas are applied"settings": {
"flow-process-duration": 86400, # 24h"total-duration": 86400# 24h
}
},
"optimizations": [ # List will be filled automatically with future script"container_memory_utilization",
"container_cpu_utilization",
"message_optimization",
"container_build_time",
"container_boot_time",
"container_image_size"
]
}
Missing features
At the moment this alteration can only be done in the database directly. For the future it is planned to create a "Create User / Update User" script that can handle this token update transparently.
Measurement quotas are not applied yet. Only API quotas so far
🌳 CO2 Data:
City: Washington, Lat: 38.7095, Lon: -78.1539
IP: 20.42.17.112
CO₂ from energy is: 0.590442790 g
CO₂ from manufacturing (embodied carbon) is: 0.114981465 g Carbon Intensity for this location: 371 gCO₂eq/kWh SCI: 0.705424 gCO₂eq / pipeline run emitted
ArneTR
changed the title
First version
Authentication in GMT
Sep 7, 2024
🌳 CO2 Data:
City: Boydton, Lat: 36.6534, Lon: -78.375
IP: 20.57.79.145
CO₂ from energy is: 0.557436740 g
CO₂ from manufacturing (embodied carbon) is: 0.117834603 g Carbon Intensity for this location: 343 gCO₂eq/kWh SCI: 0.675271 gCO₂eq / pipeline run emitted
🌳 CO2 Data:
City: Washington, Lat: 38.7095, Lon: -78.1539
IP: 20.42.43.82
CO₂ from energy is: 0.539743750 g
CO₂ from manufacturing (embodied carbon) is: 0.120117113 g Carbon Intensity for this location: 325 gCO₂eq/kWh SCI: 0.659861 gCO₂eq / pipeline run emitted
🌳 CO2 Data:
City: Boydton, Lat: 36.6534, Lon: -78.375
IP: 20.246.78.48
CO₂ from energy is: 0.507504960 g
CO₂ from manufacturing (embodied carbon) is: 0.121828996 g Carbon Intensity for this location: 302 gCO₂eq/kWh SCI: 0.629334 gCO₂eq / pipeline run emitted
🌳 CO2 Data:
City: San Jose, Lat: 37.1835, Lon: -121.7714
IP: 20.43.247.65
CO₂ from energy is: 0.335319050 g
CO₂ from manufacturing (embodied carbon) is: 0.132670921 g Carbon Intensity for this location: 187 gCO₂eq/kWh SCI: 0.467990 gCO₂eq / pipeline run emitted
* main:
Bump python from 3.12.5-slim-bookworm to 3.12.6-slim-bookworm in /docker (#898)
Bump psycopg[binary] from 3.2.1 to 3.2.2 (#900)
Bump fastapi[standard] from 0.114.0 to 0.114.2 (#899)
Added new demo data [skip ci] (#892)
Added re-licensing option
Bump pytest from 8.3.2 to 8.3.3 (#890)
Updated Cloud Energy
Bump pydantic from 2.9.0 to 2.9.1 (#889)
Adds checks to the install scripts (#886)
Bump fastapi[standard] from 0.113.0 to 0.114.0 (#887)
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR introduces the authentication functionality to GMT.
Authentication serves following functional needs:
Design considerations
GMT is designed to be a fully self-hostable and open source application. In many cases no authentication is needed for open source teams using thus.
By default GMT will install a "DEFAULT" user which however has access to all ressources, has no quotas or limits.
The authentication is designed to be transparent when not configured meaning that the frontend as well as the CLI interface will transparently inject the "DEFAULT" user whenever accessing ressources.
Only when the system is updated, new machines are added or the code is modified the authentication token ACLs must be altered.
This is the current data structure of the ACL
{ "api": { "quotas": {}, # Empty object means no quotas are applied "routes": [ "/v1/carbondb/add", "/v1/ci/measurement/add", "/v1/software/add", "/v1/hog/add", "/v1/authentication/data" ] }, "data": { "ci_measurements": { "retention": 2678400 # 31 days }, "hog_coalitions": { "retention": 2678400 # 31 days }, "hog_measurements": { "retention": 2678400 # 31 days }, "hog_tasks": { "retention": 2678400 # 31 days }, "measurements": { "retention": 2678400 # 31 days }, "runs": { "retention": 2678400 # 31 days } }, "jobs": { "schedule_modes": [ "one-off", "daily", "weekly", "commit", "variance" ] }, "machines": [ # List will be filled automatically with future script 1 ], "measurements": { "quotas": {}, # Empty object means no quotas are applied "settings": { "flow-process-duration": 86400, # 24h "total-duration": 86400 # 24h } }, "optimizations": [ # List will be filled automatically with future script "container_memory_utilization", "container_cpu_utilization", "message_optimization", "container_build_time", "container_boot_time", "container_image_size" ] }Missing features
Measurement quotas are not applied yet. Only API quotas so fardata retention limit is not implemented yet