feat: use different consul service policy rule for service role

[jim-wang-yutsung]

Closes: #3257

Signed-off-by: Jim Wang (Intel) [email protected]

If your build fails due to your commit message not passing the build checks, please review the guidelines here: https://github.com/edgexfoundry/edgex-go/blob/main/.github/Contributing.md

PR Checklist

Please check if your PR fulfills the following requirements:

• [x ] I am not introducing a breaking change (if you are, flag in conventional commit message with BREAKING CHANGE: describing the break)
• [x ] I am not introducing a new dependency (add notes below if you are)
• I have added unit tests for the new feature or bug fix (if not, why?) same unit test for regression and make test still works
• [x ] I have fully tested (add details below) this the new feature or bug fix (if not, why?)
• I have opened a PR for the related docs change (if not, why?)

Testing Instructions

1. git clone this branch and build security-bootstrapper docker image: make docker_security_bootstrapper

2. go to edgex-compse repo and use this local built image for security-bootstrapper in the docker-compose file, i.e.: make gen dev or run it with make run dev

3. run it up with docker-compose or make run dev

4. once the stack is up, please obtain the consul admin token via make get-consul-acl-token and we will use it to verify policies and tokens were generated by login into consul UI and check them.

5. Use consul admin token to login consul in any browser at http://localhost:8500

6. After login, go to Policy view (click on Policies hyperlink on the left panel) and check that policies were generated for all services, something looks like the following:
   

7. Then go to Token view (click on Tokens hyperlink on the left panel) and check that consul tokens were generated per service policy:
   

8. Now we can test the key-value store only accessible to its own service per kv api point of view: copy the app-http-export's consul token and export it and then use it to read some key of its own:

# use http-export's consul token
export CONSUL_TOKEN=057fcff7-2a4e-15ab-a115-e64cda7f28b9
curl -H "X-Consul-Token:${CONSUL_TOKEN}" -X GET "http://localhost:8500/v1/kv/edgex/appservices/2.0/app-http-export/Database/Host"

[{"LockIndex":0,"Key":"edgex/appservices/2.0/app-http-export/Database/Host","Flags":0,"Value":"ZWRnZXgtcmVkaXM=","CreateIndex":548,"ModifyIndex":548}]

as we can see its own consul token works for kv read, now we can also test kv write for its own key:

curl -H "X-Consul-Token:${CONSUL_TOKEN}" -X PUT "http://localhost:8500/v1/kv/edgex/appservices/2.0/app-http-export/Database/Host" -d 'test consul'

true

10. Now we use different consul token from other service to test if kv read is restricted or not:

export CONSUL_TOKEN=3c7f7fd0-7170-4c8a-4c4c-f36f5a672f15
try to read app-http-export:
curl -H "X-Consul-Token:${CONSUL_TOKEN}" -X GET "http://localhost:8500/v1/kv/edgex/appservices/2.0/app-http-export/Database/Host"
Permission denied: token with AccessorID '154e821e-325b-2681-a45f-6e3ca6141b77' lacks permission 'key:read' on "edgex/appservices/2.0/app-http-export/Database/Host"

so kv read is permission denied when we use other's consul token to access read it.

12. And we can also test the kv write using other consul token:

curl -H "X-Consul-Token:${CONSUL_TOKEN}" -X PUT "http://localhost:8500/v1/kv/edgex/appservices/2.0/app-http-export/Database/Host" -d 'edgex-redis'
Permission denied: token with AccessorID '154e821e-325b-2681-a45f-6e3ca6141b77' lacks permission 'key:write' on "edgex/appservices/2.0/app-http-export/Database/Host"

again, the kv write permission is denied as we intended it to.

New Dependency Instructions (If applicable)

[lenny-goodell]

LGTM, but not expert in this area. Will defer to @bnevis-i

[jim-wang-yutsung]

Discussed with Bryon, @bnevis-i and we put this on hold in draft because there is no clean way to determine the dynamic structure for key-prefix from security-bootstrapper point of view:

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

No Coverage information
0.0% Duplication

[lenny-goodell]

LGTM, deferring to @bnevis-i for final approval

changes addressed

[bnevis-i]

LGTM. Does exactly what I expect it to do.