nais / device Goto Github PK

When user authenticates against Azure AD, we spin up a webserver on localhost which is configured in AAD to be the replyURL of the authorization code.

Investigate if it's possible to redirect to the naisdevice agent app instead, and avoid having to open the users browser.

Possibly relevant link: https://docs.microsoft.com/en-us/azure/active-directory/develop/redirect-uris-ios

The device health checker only fetches failures for the Kolide devices if the failure_count attribute of the device is larger than the resolved_failure_count attribute. The issue is that resolved_failure_count is an always increasing number, while failure_count reflects the current amount of failing checks for the device, and will reset to 0 when a failure has been resolved.

enable logshipping from journald on apiserver and gateways to provide transparency

add logging of relevant user events on specified format. See device-health-checker for reference.

use audit level on these logs to enable filtering

ERRO[2020-06-04T08:17:23+02:00] Unable to get gateway config: getting device config: Get http://10.255.240.1/devices/C02X1CGMJG5J/gateways: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"AADSTS70043: The refresh token has expired or is invalid due to sign-in frequency checks by conditional access. The token was issued on 2020-06-03T07:09:26.9675714Z and the maximum allowed lifetime for this request is 82800.\r\nTrace ID: 39de2a28-2749-4a6e-8aeb-f05d97ad0701\r\nCorrelation ID: 672adb9a-e472-40ac-a220-c48f11499d90\r\nTimestamp: 2020-06-04 06:17:23Z","error_codes":[70043],"timestamp":"2020-06-04 06:17:23Z","trace_id":"39de2a28-2749-4a6e-8aeb-f05d97ad0701","correlation_id":"672adb9a-e472-40ac-a220-c48f11499d90","suberror":"token_expired"}

TTSIA

Users should find our documentation at doc.nais.io/device

Atm the gateway-agent will always setup the wg interface (teardown+setup), which disconnects everyone. Instead of teardown we can check if the wg interface is already set up, and just skip that step if it is (or allow the ip link add command to fail).

last_check and last_seen should be renamed.

last_check is only updated by the API server, and this occurs when a device is updated. Rename to last_updated?

last_seen is when Kolide last saw the device. Rename to kolide_last_seen?

It looks like devices that are not enrolled in Kolide gets a default healthy: true, should just be discarded or false

Today we use terraform to set up the VM, networking, secrets and serviceusers.
The rest of the setup: packages, systemd and kernel settings are set manually, and should be automated.

verify that combination of username and serial from apiserver matches info in Kolide

After running agent for a while, this occurs:

INFO[2020-05-27T17:53:56+02:00] Starting device-agent with config:
{APIServer:http://10.255.240.1 Interface:utun69 ConfigDir:/Users/hrv/Library/Application Support/naisdevice BinaryDir:/usr/local/bin BootstrapToken: WireGuardBinary: WireGuardGoBinary: PrivateKeyPath: WireGuardConfigPath: BootstrapConfigPath: LogLevel:info OAuth2Config:{ClientID:8086d321-c6d3-4398-87da-0d54e3d93967 ClientSecret: Endpoint:{AuthURL:https://login.microsoftonline.com/62366534-1ec3-4962-8869-9b5535279d0b/oauth2/v2.0/authorize TokenURL:https://login.microsoftonline.com/62366534-1ec3-4962-8869-9b5535279d0b/oauth2/v2.0/token AuthStyle:0} RedirectURL:http://localhost:51800 Scopes:[openid 6e45010d-2637-4a40-b91d-d4cbb451fb57/.default offline_access]} Platform: BootstrapAPI:https://bootstrap.device.nais.io}
INFO[2020-05-27T17:53:56+02:00] If the browser didn't open, visit this url to sign in: https://login.microsoftonline.com/62366534-1ec3-4962-8869-9b5535279d0b/oauth2/v2.0/authorize?access_type=offline&client_id=8086d321-c6d3-4398-87da-0d54e3d93967&code_challenge=xxx-sg6nXyE4SnuZ0&code_challenge_method=S256&redirect_uri=http%3A%2F%2Flocalhost%3A51800&response_type=code&scope=openid+6e45010d-2637-4a40-b91d-d4cbb451fb57%2F.default+offline_access&state=HrNmLh1i5iNSf9YB
Starting device-agent-helper, you might be prompted for password
Password:
INFO[2020-05-27T17:54:02+02:00] Starting device-agent-helper with config:
{Interface:utun69 BinaryDir: WireGuardBinary:/usr/local/bin/naisdevice-wg WireGuardGoBinary:/usr/local/bin/naisdevice-wireguard-go WireGuardConfigPath:/Users/hrv/Library/Application Support/naisdevice/wg0.conf LogLevel:info DeviceIP:10.255.240.9}
ERRO[2020-05-27T19:04:23+02:00] Unable to get gateway config: getting device config: Get http://10.255.240.1/devices/SERIAL/gateways: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"AADSTS70043: The refresh token has expired or is invalid due to sign-in frequency checks by conditional access. The token was issued on 2020-05-22T18:38:20.0528180Z and the maximum allowed lifetime for this request is 82800.\r\nTrace ID: 5d0a143c-3d3e-4872-8ac6-be1628421e00\r\nCorrelation ID: 39a0d8d8-368d-4237-ae96-9a8ddf1574f8\r\nTimestamp: 2020-05-27 17:04:23Z","error_codes":[70043],"timestamp":"2020-05-27 17:04:23Z","trace_id":"5d0a143c-3d3e-4872-8ac6-be1628421e00","correlation_id":"39a0d8d8-368d-4237-ae96-9a8ddf1574f8","suberror":"token_expired"}

Currently we are only fetching failing devices from the Kolide API. Instead we need to fetch all devices to be able to update the database with the "last seen" timestamp.

Depends on #22.

naisdevice needs a logo

As a user it's helpful to know which gateways I can access, and which I can't and why.
If my device is in a unhealthy according to the apiserver, I should be informed about this

Må modellere inn informasjon om hvilke CIDRs gatewayen skal være proxy for.
Vi har i dag to typer gateways, en som kun er en nat-gw (f.eks azure-gw) og en som proxyer trafikk (apiservere i GCP). Dette må skilles på i modellen slik at gateway-agent kan konfigurere iptables riktig avhengig av hvilken type gateway den er.

Kan muligens bare utledes ved at gatewayen ikke har definert noen routes.

if len(gateway.routes) == 0 {
  // proxy type
} else {
  // nat type
}

This is probably because user location changes when going through gateway

Currently it takes ~20 seconds before all timers have run in a order to allow reaching the gateways

1. device-agent-helper takes 10 seconds to run sync on the bootstrap-config
2. this allows device-agent, about 5 seconds later, to get gateways from apiserver
3. 10 seconds later, these are synced and made available for user

Serial is not unique by itself, it needs to be used in a compound key with "platform". Kolide uses the following values for platform (for the devices we have currently registered):

• rhel
• ubuntu
• windows
• darwin

Make use of and continously rotate PresharedKeys to ensure valid user and device

ATOM - @toby1knby
Jonas - @gorzan
Leif/Dammen - Bente
Nettverk/sikkerhet - @toby1knby

Bestemme oss for et antall, sørge for å ha lisenser klare

We need to track when devices was last seen in Kolide. Add a field for this in the database.

Currently, if the tunnel stops working it will end up in a never ending loop because:

• We add routes that tunnel Microsoft-traffic through a gateway
• We use azure ad auth on our api server

In the scenario where the microsoft gateway stops working, we're unable to fetch new access tokens, and therefore unable to communicate with the api.

We should consider making "full disk access" a requirement for Macs to become nice device. Several checks and possibly future checks are crippled if Kolide does not have full access.

• instrument gateway-agent and apiserver with relevant metrics
• setup metrics-rig, prometheus on own server? must communicate over tunnel
• prometheus available as DS for common grafana instance

metrics:
gateways:
- throughput (gateways)
- device count
apiserver:
- device count
- healthy/unhealthy count
- apicalls by code
healthchecker:
- platformtype count

alerts:

• if gateways or apiserver goes down
• x time since healthchecker has run
• ..

We need to keep track over Kolide checks to make sure we have a correct criticality level set.

Create a scheduled workflow to check this.

device-agent-helper sometimes fail due to existing wireguard-go process (that for unknown reasons were not killed when a previous instance of device-agent-helper exited)

We could check for and kill existing wireguard-go processes when we start device-agent-helper

For å forenkle installasjon / bruk av device health update skal det genereres phar pakker.

Det bør laget to pakker, en for "update" og en for "get-checks". Dette kan legges til i hovedworkflowen til master-branchen. Det kan også lages snapshots for andre branches.

Is "missing" from the Linux tables in Osquery. We need a discussion on how to mitigate/solve this requirement.

Some of our users seem to not appreciate the kekw meme as much as we do.

Now that Kolide have a concept around tags we should use these for check severity.

Currently all checks in Kolide have been tagged with the correct levels, according to the existing severity levels found in the configuration file.