Skip to content

Security: objectbox/edgex-objectbox

Security

SECURITY.md

Security Components in EdgeX Foundry Services

Starting with the Fuji release, EdgeX includes enhanced security features that are enabled by default. There are 3 major components that are responsible for security features:

Security-secrets-setup is responsible for creating necessary certificates. Security-secretstore-setup is responsible for initializing the secret store to hold various credentials for EdgeX. Security-proxy-setup is responsible for initializating the EdgeX proxy environment, which includes setting up related permissions and authentication methods. The proxy will protect all the REST API resources.

Get Started

To get started, fetch the latest docker-compose.yml and start the EdgeX containers:

$ wget https://raw.githubusercontent.com/edgexfoundry/developer-scripts/master/releases/fuji/compose-files/docker-compose-fuji-1.1.0.yml
$ docker-compose up -d

Once EdgeX is up and running, the following steps are required to access EdgeX resources:

  1. The user needs to create an access token and associate every REST request with the security token while sending the request. Use "admin" as group name below, as it is the privileged group in the default configuration of the proxy. <account> below should be substituted for the desired account name (e.g., "mary", "iot_user", etc). Due to different docker-compose file configuration the command may need to be adjusted. E.g, for docker compose file that comes from nightly-build folder, it may be necessary to change the execution portion of the entry point of edgex-proxy to provide proper command flags like this:

    /edgex/security-proxy-setup --init=false --useradd=<account> --group=<groupname> 

    then run

    $ docker-compose run edgex-proxy

    which will create an access token. One example of an access token is: eyJpc3MiOiI5M3V3cmZBc0xzS2Qwd1JnckVFdlRzQloxSmtYOTRRciIsImFjY291bnQiOiJhZG1pbmlzdHJhdG9yIn0.
    Yours will differ from this one.

  2. The exported external ports (such as 48080, 48081 etc.) will be inaccessible for security reasons. Instead, all the REST requests need to go through the proxy, and the proxy will redirect the request to individual microservice on behalf of the user.

    E.g, if we need to send a request to the ping endpoint of coredata, without security this would look like:

    $ curl http://{coredata-microservice-ip}:48080/api/v1/ping
    

    With security services enabled, the request would look like this:

    $ curl -k https://{proxy-service-ip}:8443/coredata/api/v1/ping -H "Authorization: Bearer <access-token>"
    

    Note the request is made over https to the proxy-service's IP address on port 8443. The access token is also included in the Authorization header.

Community

License

Apache-2.0

There aren’t any published security advisories