- Update the form to use BooleanFields for the permissions and make the
form more similar to the Application Members form
- Use MemberFormTemplate macro in the portfolio settings template
- fix tests affected by the form changes
Before this commit, if a portfolio wasn't present in the spending fixture
data, the reporting screen would be empty -- even if the portfolio had
applications and environments associated with it on the database. Now,
0s appear if an application and / or environment isn't present in the
fixture data.
The implementation here is meant to wrap a library of JSON policy
documents. Policies should be added to directories corresponding to
where they will be defined (portfolio, application, environment).
Functionality for parsing portfolio policy definitions is included. When
the policies need to be defined on a management group, the
AzureCloudProvider can iterate the appropriate tier of the policy
manager and add those definitions.
This adds some initial example policies:
- One for region restrictions
- One for service restrictions
Note that the MS ARM team has said that region restrictions may be
controlled by ARM, so that policy might prove unnecessary. The
parameters list for the service restrictions is stubbed for now, pending
the full list.
I also added an internal method for adding policy definitions to a
management group. This method is agnostic about what tier of management
group the policy is being defined at. It requires that a dictionary
representing the properties section of a valid Azure JSON policy
definition be passed as an argument.
This commit lays out the genral structure and provides necessary
data for the new reporting page designs.
Some of the data generated by the report domain classes (including
the mock CSP reporting class) was modified to fit new designs. This also
included removing data that was no longer necessary. Part of the newly
mocked data includes the idea of "expended" data per CLIN or task order.
This was was mocked simply by using a 75% of the obligated funds fo a
given object. Tests were also written for these new/ modifed reporting
functions.
As for the front end, this commit only focuses on the high-level markup
layout. This includes splitting the large reporting index page into
smaller component templates for each of the major sections of the report.
disabled env role
We were only checking to see if a role was disabled or deleted before
raising an error, so I added in a check to see if the user was trying to
update the env role before raising an error. The error should only be
raised if the role is disabled or deleted AND the user is trying to
assign a new role to the env role.
I also added in a disabled property to the EnvironmentRole model to make
things more readable.
A CRL test that relies on fixtures files was not getting a working copy
of the relevant CRL list it needed. This also adds a setup function to
the relevant test module so that we can clear and rebuild the CRL
location cache for the fixtures.
This change makes it so that when an env_role is updated to be None, the
role property on the env_role is changed to be None in addition to being
marked as deleted. This also adds in a check so that previously deleted
env_roles cannot be reassigned a role.
The previous solution (ad-hoc stream-parsing the CRLs to obtain their
issuers and nextUpdate) was too cute. It began breaking on CRLs that had
an addition hex 0x30 byte somewhere in their header. I thought that 0x30
was a reserved character only to be used for tags in ASN1 encoded with
DER; turns out that's not true. Rather than write a full-fledged ASN1
stream-parser, the simplest solution is to just maintain the list of
issuers as a constant in the codebase. This is fine because the issuer
for a specific CRL URI should not change. If it does, we've probably got
bigger problems.
This also removes the Flask app's functionality for updating the local
CRL cache. This is being handled out-of-band by a Kubernetes CronJob
and is not a concern of the app's. This means that instances of the
CRLCache do not have to explicitly track expirations for CRLs.
Previously, the in-memory dictionary or CRL issuers and locations
included expirations; now it is flattened to not include that
information.
The CRLCache class has been updated to accept a crl_list kwargs so that
unit tests can provide their own alternative CRL lists, since we now
hard-code the expected CRLs and issuers. The nightly CRL check job has
been updated to check that the hard-coded list of issuers matches what
we get when we actually sync the CRLs.
AT-AT needs to maintain a key-value CRL cache where each key is the DER
byte-string of the issuer and the value is a dictionary of the CRL file
path and expiration. This way when it checks a client certificate, it
can load the correct CRL by comparing the issuers. This is preferable to
loading all of the CRLs in-memory. However, it still requires that AT-AT
load and parse each CRL when the application boots. Because of the size
of the CRLs and their parsed, in-memory size, this leads to the
application spiking to use nearly 900MB of memory (resting usage is
around 50MB).
This change introduces a small function to ad-hoc parse the CRL and
obtain the information in the CRL we need: the issuer and the
expiration. It does this by reading the CRL byte-by-byte until it
reaches the ASN1 sequence that corresponds to the issuer, and then looks
ahead to find the nextUpdate field (i.e., the expiration date). The
CRLCache class uses this function to build its cache and JSON-serializes
the cache to disk. If another AT-AT application process finds the
serialized version, it will load that copy instead of rebuilding it. It
also entails a change to the function signature for the init method of
CRLCache: now it expects the CRL directory as its second argument,
instead of a list of locations.
The Python script invoked by `script/sync-crls` will rebuild the
location cache each time it's run. This means that when the Kubernetes
CronJob for CRLs runs, it will refresh the cache each time. When a new
application container boots, it will get the refreshed cache.
This also adds a nightly CircleCI job to sync the CRLs and test that the
ad-hoc parsing function returns the same result as a proper parsing
using the Python cryptography library. This provides extra insurance
that the function is returning correct results on real data.
