internal: migrate to zap from logrus

[BeryJu]

Details

REPLACE ME

---

Checklist

• Local tests pass (ak test authentik/)
• The code has been formatted (make lint-fix)

If an API change has been made

• The API schema has been updated (make gen-build)

If changes to the frontend have been made

• The code has been formatted (make web)

If applicable

• The documentation has been updated
• The documentation has been formatted (make website)

[netlify]

✅ Deploy Preview for authentik-docs canceled.

Name	Link
🔨 Latest commit	561b0ce
🔍 Latest deploy log	https://app.netlify.com/sites/authentik-docs/deploys/67731861afe8d50008df71bd

[netlify]

✅ Deploy Preview for authentik-storybook canceled.

Name	Link
🔨 Latest commit	561b0ce
🔍 Latest deploy log	https://app.netlify.com/sites/authentik-storybook/deploys/6773186189bcbb0008a5bc13

To fix the problem, we need to ensure that any sensitive information in the fields map is either encrypted, obfuscated, or omitted entirely before being logged. The best way to achieve this without changing existing functionality is to cleanse the headers before logging them. We can create a helper function to cleanse the headers and use it before logging the fields map.

1. Create a helper function cleanseHeaders to remove or obfuscate sensitive information from the headers.
2. Use this helper function to cleanse the fields map before logging it in the ReportMisconfiguration function.

To fix the problem, we should avoid logging sensitive information contained in HTTP headers. Instead of logging the entire header, we can log only non-sensitive parts or obfuscate sensitive values. We can create a function to cleanse the headers by removing or masking sensitive information before logging.

• Create a function cleanseHeaders to remove or mask sensitive information from the headers.
• Replace the logging call on line 29 to use the cleansed headers.

To fix the problem, we need to ensure that sensitive information in HTTP headers is not logged in clear text. The best way to achieve this is to cleanse the headers before logging them, removing or obfuscating any sensitive information. We can create a helper function to cleanse the headers and use this function before logging.

• Create a helper function cleanseHeaders to remove or obfuscate sensitive information from the headers.
• Replace the logging statement on line 72 to use the cleansed headers.

To fix the problem, we should avoid logging sensitive information contained in HTTP headers. Instead of logging the entire header, we can log only non-sensitive parts or obfuscate sensitive values. We can create a function to cleanse the headers by removing or masking sensitive information before logging.

• Create a function cleanseHeaders to remove or mask sensitive information from headers.
• Replace the logging of headers with the cleansed version of the headers.
• Ensure the changes are made in the forwardHandleNginx and forwardHandleEnvoy functions.

To fix the problem, we should avoid logging the entire HTTP headers directly. Instead, we can log only non-sensitive parts of the headers or obfuscate sensitive information before logging. We can create a function to cleanse the headers by removing or masking sensitive information before logging them.

• Create a function cleanseHeaders to remove or mask sensitive information from the headers.
• Replace the direct logging of r.Header with the cleansed version of the headers.

To fix the problem, we should avoid logging the entire HTTP headers in clear text. Instead, we can log only non-sensitive parts of the headers or obfuscate sensitive information before logging. In this case, we will remove the logging of headers entirely to ensure no sensitive information is exposed.

• Remove the logging of HTTP headers on line 109.
• Ensure that the functionality of the application remains unchanged.

To fix the problem, we should avoid logging the host value directly. Instead, we can obfuscate or sanitize the host value before logging it. One approach is to hash the host value, which ensures that the original value is not logged in clear text while still allowing us to identify unique hosts.

We will use the crypto/sha256 package to hash the host value before logging it. This change will be made in the Handle and lookupApp functions in the internal/outpost/proxyv2/handlers.go file.

To fix the problem, we should avoid logging the host value directly. Instead, we can either sanitize the host value before logging or omit it entirely from the log message. In this case, we will omit the host value from the log message to ensure no sensitive information is exposed.

• Remove the zap.String("host", host) from the logging statements in internal/outpost/proxyv2/handlers.go.
• Ensure that the functionality of the application remains unchanged by only modifying the logging statements.

To fix the problem, we should avoid logging the entire HTTP request headers directly. Instead, we can log only non-sensitive parts of the headers or obfuscate sensitive information before logging. In this case, we will remove the logging of the headers entirely to ensure no sensitive information is exposed.

• Remove the zap.Any("headers", req.Header) from the logging statement on line 31.
• Ensure that the rest of the logging statement remains unchanged to maintain existing functionality.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.69%. Comparing base (8938fa5) to head (561b0ce).
Report is 1 commits behind head on main.

✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #12521      +/-   ##
==========================================
- Coverage   92.75%   92.69%   -0.06%     
==========================================
  Files         770      770              
  Lines       38873    38873              
==========================================
- Hits        36057    36035      -22     
- Misses       2816     2838      +22     

Flag	Coverage Δ
e2e	48.60% <ø> (-0.10%)	⬇️
integration	24.58% <ø> (ø)
unit	90.38% <ø> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

authentik PR Installation instructions

Instructions for docker-compose

Add the following block to your .env file:

AUTHENTIK_IMAGE=ghcr.io/goauthentik/dev-server
AUTHENTIK_TAG=gh-561b0ceca6be620bc0965da01c366f0eceac90d6
AUTHENTIK_OUTPOSTS__CONTAINER_IMAGE_BASE=ghcr.io/goauthentik/dev-%(type)s:gh-%(build_hash)s

For arm64, use these values:

AUTHENTIK_IMAGE=ghcr.io/goauthentik/dev-server
AUTHENTIK_TAG=gh-561b0ceca6be620bc0965da01c366f0eceac90d6-arm64
AUTHENTIK_OUTPOSTS__CONTAINER_IMAGE_BASE=ghcr.io/goauthentik/dev-%(type)s:gh-%(build_hash)s

Afterwards, run the upgrade commands from the latest release notes.

Instructions for Kubernetes

Add the following block to your values.yml file:

authentik:
    outposts:
        container_image_base: ghcr.io/goauthentik/dev-%(type)s:gh-%(build_hash)s
global:
    image:
        repository: ghcr.io/goauthentik/dev-server
        tag: gh-561b0ceca6be620bc0965da01c366f0eceac90d6

For arm64, use these values:

authentik:
    outposts:
        container_image_base: ghcr.io/goauthentik/dev-%(type)s:gh-%(build_hash)s
global:
    image:
        repository: ghcr.io/goauthentik/dev-server
        tag: gh-561b0ceca6be620bc0965da01c366f0eceac90d6-arm64

Afterwards, run the upgrade commands from the latest release notes.