Confidant

Latest version: v6.5.3

Safety actively analyzes 621469 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 1 of 7

6.4.0

* Updated client with a new logo and updated CSS to match design style guide. The new CSS coloring should
be more consistent across the client, and should have higher contrast.

6.3.0

* Added support for keeping track of when credentials should be rotated.
Three new fields have been added to the Credential model:

* tags: `tags` are a set of strings that can be used to categorize a credential. For instance
"ADMIN_PRIV" or "EXEMPT_FROM_ROTATION" could be potential tags. We choose to have a list of tags
rather than a single string because some credentials might fall into multiple categories
* last_decrypted_date: `last_decrypted_date` explicitly stores when someone viewed a credential.
Certain credentials can potentially be highly vulnerable and could benefit from being rotated
the moment the credential pair is viewed.
* last_rotation_date: `last_rotation_date` stores when a credential was last rotated. Some credentials
might need to periodically be rotated for security purposes.

There is also additional logic for calculating when a credential should next be rotated
given its previous rotation history. This logic lives as the `next_rotation_date` property on the
Credential object and is not persisted into the DB layer. To use this logic:

1. Set an env variable `MAXIMUM_ROTATION_DAYS` which determines how the maximum amount of time before
a credential should be rotated. By default, `MAXIMUM_ROTATION_DAYS` is 0 so people using this feature
must explicitly set it.
1. Set an env variable `ROTATION_DAYS_CONFIG` which is a JSON serialized string. This is just a key value
config where the key represents a tag (eg: "ADMIN_PRIV") and the value represents the number of days
that keys with this tag should be rotated. For instance, we could have a `ROTATION_DAYS_CONFIG` that
looks something like '{"ADMIN_PRIV": 30, "FINANCIAL_DATA": 10}'

* Add a `metadata_only` param to `GET /v1/credentials/<ID>`. For instance, if the request is
`GET /v1/credentials/123?metadata_only=true`, the response will not contain the credential pairs.
`metadata_only` defaults to `false` so that it is backwards compatible. The purpose of this
is to give users finer controls when deciding whether to send back `credential_pairs`.

* Automatically update the `last_decrypted_date` on a credential when the `credential_pairs` are
sent back to the client. Sending `credential_pairs` to the client implies that a credential has been
decrypted and is likely to have been read by a human. This is also an OPT IN change.
An environment variable `ENABLE_SAVE_LAST_DECRYPTION_TIME` must be set to true in order to
update `last_decrypted_date`.

* Added `config/gunicorn.conf` and `config/logging.conf` files, which can be used to enable structured
json logs for logging output.

* Updated the docker-compose setup to have a fully functional production-like environment, with
local dynamodb, local kms, and a local simplesamlphp IDP. The developer environment also has a
configuration for the PKI, which will generate self-signed certificates.

* Fix for issue with `HISTORY_PAGE_LIMIT`, where when unset, the client would not load any history. If
`HISTORY_PAGE_LIMIT` is now unset, it will correctly use the default behavior of not paging.

6.2.0

Not secure
* This release fixes a python3 stacktrace in SAML auth, when using the `SAML_SP_KEY_FILE` setting.

6.1.0

Not secure
* This release adds support for confidant acting as a Certificate Authority,
using AWS Certificate Manager Private Certificate Authority. Four new endpoints
have been added:

* `GET /v1/certificates/<ca>/<cn>`: Have confidant generate a private key, a CSR,
and have it issue a certificate against the provided CA, with the provided CN. A
list of SANs can be provided via arguments: `?san=<domain>&san=<domain>` The validity
in number of days can be provided via arguments: `?validity=120` The maximum validity
is controlled server side via a configuration setting.
* `POST /v1/certificates/<ca>`: Generate a private key and CSR from the client side,
and have confidate issue a certificate against the provided CA. SAN and validity can
be set via a json post body: `{"san": ["domain", "domain"], "validity": 120}`
* `GET /v1/cas`: Get a list of configured CAs, their certificate and certificate chains,
and a dictionary of key/value tags set on the CA in AWS.
* `GET /v1/cas/<ca>`: Get the certificate, certificate chain, and a dict of tags set on
the CA in AWS.

The implementation supports multiple CAs. For configuration information, see [the
certificate authority settings section in the docs](configuration.htmlcertificate-authority-settings).

6.0.0

Not secure
* This release is a breaking release. This release slightly changes the API
responses. Though the changes should be backwards incompatible, we're now
explicitly returning all fields in returns, rather than not including
fields that have nil values in the json. Clients that expect fields to not
exist could be affected by this change. The offical python client has been
tested against these changes, but there's a number of unofficial libraries
that you will want to test, if you're using one of them.
* DEPRECATION NOTICE: This will be the last confidant release that will support
python2.
* DEPRECATION NOTICE: This will be the last confidant release that will support
blind credentials. If you're using blind credentials, we recommend switching
to standard credentials, and protecting access to them using the new access
control (ACL) support hooks to provide fine-grained access control.
* Confidant is now python3 compatible, and tested against python 3.6, 3.7 and
3.8. If you see any python3 related issues, please open an issue.
* Confidant now includes an access control plugin framework, with a default
plugin, `confidant.authnz.rbac:default_acl`, which implements the existing
access control behavior of confidant. The `ACL_MODULE` setting can be used
to define your own ACL behavior; see the [ACL docs](acls.html)
for information about how to apply fine-grained access controls to specific
resources and actions.
* kmsauth was upgraded with a more efficient LRU implementation, which allows
for higher concurrency.
* The frontend and backend have been refactored to only provide sensitive data
where necessary. For example, previously, when viewing a service, the
credentials for that service were included in the response. Now when the
frontend fetches a service, it only fetches credential metadata that it uses
for display purposes. Similarly, the history view no longer fetches or
displays sensitive information. These changes were made to support fine-grained
access controls.
* The resources and history view list panels no longer combine resources in the
view, but include a resource type toggle, to make it easier to find resources.
* The history backend endpoints that list resources now support paged results.
Future releases will expand this to all endpoints that list resources. Default
behavior for these endpoints is to not page results. Clients can limit the
page size via an argument. It's also possible to force paging for these
via the `HISTORY_PAGE_LIMIT` setting.
* New backend endpoints have been added to support reverting credential and
service resources, rather than needing to do an edit of resources, with all
fields. This was in support of adding fine-grained access controls, but also
makes reverting resources trivial from the client side.
* `GET /v1/services/<id>` now supports a `metadata_only=[True|False]` argument
which can be used to only include metadata in the response.
* Permissions hints are included in the response of resource endpoints, to
allow the UI (and other clients) to adjust their behavior based on permissions
available.
* More detailed audit logs have been added for user actions, such as get/update credential,
and get/update service.
* Google OAuth support has been updated to work with the new Google Sign-In APIs,
rather than the older Google+ Sign-In APIs.

5.2.0

Not secure
* Python3 fix in function ``load_private_key_pem`` in ``confidant.lib.cryptolib``

Page 1 of 7

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.