Run pulpcore-manager check --deploy in acceptance

[ekohl]

Django has a checks framework that can detect problems in a deployment. It's also extensible and allows Pulp and plugin developers to add their own checks. This allows detection of misconfigurations.

Some checks run implicitly before running certain commands but others don't for performance reasons.

--deploy signals that a production setup is used, which enables more checks.

https://docs.djangoproject.com/en/2.2/topics/checks/

[ekohl]

So there's 9 warnings:

• (guardian.W001) Guardian authentication backend is not hooked. You can add this in settings as eg: AUTHENTICATION_BACKENDS = ('django.contrib.auth.backends.ModelBackend', 'guardian.backends.ObjectPermissionBackend').

We follow https://docs.pulpproject.org/pulpcore/installation/authentication.html#webserver-authentication and that causes this. Need to reach out to upstream.

• (security.W004) You have not set a value for the SECURE_HSTS_SECONDS setting. If your entire site is served only over SSL, you may want to consider setting a value and enabling HTTP Strict Transport Security. Be sure to read the documentation first; enabling HSTS carelessly can cause serious, irreversible problems.

I think HSTS is irrelevant for Pulp. Some content should be available over HTTPS and most API clients ignore HSTS anyway. It's mostly browsers. Should be masked. Maybe even from an upstream point of view?

• (security.W006) Your SECURE_CONTENT_TYPE_NOSNIFF setting is not set to True, so your pages will not be served with an 'X-Content-Type-Options: nosniff' header. You should consider enabling this header to prevent the browser from identifying content types incorrectly.

Reading https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options this looks like it might be a good thing to include. Should talk to upstream about this because I don't know how much security it actually brings.

• (security.W007) Your SECURE_BROWSER_XSS_FILTER setting is not set to True, so your pages will not be served with an 'X-XSS-Protection: 1; mode=block' header. You should consider enabling this header to activate the browser's XSS filtering and help prevent XSS attacks.

Reading https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection I wonder if this is really relevant. Especially considering Pulp is mostly an API anyway.

• (security.W008) Your SECURE_SSL_REDIRECT setting is not set to True. Unless your site should be available over both SSL and non-SSL connections, you may want to either set this setting True or configure a load balancer or reverse-proxy server to redirect all connections to HTTPS.

I think this should be masked since there is deliberate HTTP content.

• (security.W009) Your SECRET_KEY has less than 50 characters or less than 5 unique characters. Please generate a long and random SECRET_KEY, otherwise many of Django's security-critical features will be vulnerable to attack.

Looks like we should really up our secret key generation.

• (security.W012) SESSION_COOKIE_SECURE is not set to True. Using a secure-only session cookie makes it more difficult for network traffic sniffers to hijack user sessions.

Not sure if this is relevant since we don't use sessions. I think it can be masked.

• (security.W016) You have 'django.middleware.csrf.CsrfViewMiddleware' in your MIDDLEWARE, but you have not set CSRF_COOKIE_SECURE to True. Using a secure-only CSRF cookie makes it more difficult for network traffic sniffers to steal the CSRF token.

Sounds like something upstream should do?

• (security.W019) You have 'django.middleware.clickjacking.XFrameOptionsMiddleware' in your MIDDLEWARE, but X_FRAME_OPTIONS is not set to 'DENY'. The default is 'SAMEORIGIN', but unless there is a good reason for your site to serve other parts of itself in a frame, you should change it to 'DENY'.

Also a good question to upstream.

[ekohl]

@daviddavis you asked me about checks. IMHO this is something the installer could run as well. sosreport is another.

[theforeman-bot]

@ekohl, this pull request is currently not mergeable. Please rebase against the master branch and push again.

If you have a remote called 'upstream' that points to this repository, you can do this by running:

    $ git pull --rebase upstream master

---

This message was auto-generated by Foreman's prprocessor

[ekohl]

I've dropped the --fail-level WARNING part so it matches theforeman/foremanctl#352

[evgeni]

Does rspec validate all assertions, or does it stop at the first failing one? If it's the first, asserting the output first makes the result better actionable.

[ekohl]

Should be all as separate checks. It may also execute the command for every check so that's a bit slower.

[ekohl]

I see a lot of type hint errors. @evgeni did you also see these in foremanctl?

[evgeni]

I think so, yes. But as those are only warnings, the exit code should still be 0.

Maybe that's why we don't assert the stdout in foremanctl?
https://github.com/theforeman/foremanctl/blob/cc2a0a71b54bfb85e929a3aa8a612207b7f0d8d8/tests/pulp_test.py#L73-L75