Introduction:
While performance secondary clusters are used as read replicas in the vault for scaling purposes, it is also imperative to know that PR secondary clusters continue to allow approle login operations even when the primary cluster is down. While this is the default behavior, the login operations might fail in certain scenarios if the secret_id_num_uses parameter is used to control the uses number of secret_id. This article outlines the effective way to implement approle configuration so that approle login continues to work even if the primary cluster is down in an adverse situation.
Summary:
secret_id_num_uses parameter is used to control the number of login against unique secret_id as security best practices. While this is used, the primary cluster keeps track of of number of uses of secret_id using a counter. If and when the primary cluster is down, and a login is attempted on the performance secondary cluster; the login fails as the primary needs to be available for writing the num_uses counter into storage.
To avoid this, local_secret_ids parameter can be set to true during role creation. This would ensure that secret_ids created against the role is local to the cluster. Hence, the num_uses counter gets tracked specifically to the cluster; and approle login continues to work in the performance secondary cluster even when the primary cluster is down.
Example test case:
Case 1 : let's create an app-role named role-with-num-use with secret_id_num_uses set to a number. Fetch the role-id of the role. This can be performed on any cluster (Primary or Performance secondary):
vault@primary:~/vault$ vault write -f auth/approle/role/role-with-num-use secret_id_num_uses=20
Success! Data written to: auth/approle/role/role-with-num-use
vault@primary:~/vault$ vault read auth/approle/role/role-with-num-use/role-id
Key Value
--- -----
role_id be2f555e-9243-385b-3b38-2d6547050a3f
Generate a secret-id of the new app-role. This can be performed on any cluster (Primary or performance secondary):
vault@pr-sec:~/vault/plugins$ vault write -f auth/approle/role/role-with-num-use/secret-id
Key Value
--- -----
secret_id 2c2b37d2-74f8-6510-0399-9295a4acdc21
secret_id_accessor 18e8b04d-1c8c-4a7c-607c-fea9dba09b64
secret_id_num_uses 20
secret_id_ttl 0s
Perform a login using the role-id and secret-id on performance secondary cluster.
vault@pr-sec:~/vault/plugins$ vault write -f auth/approle/login role_id=be2f555e-9243-385b-3b38-2d6547050a3f secret_id=2c2b37d2-74f8-6510-0399-9295a4acdc21
Key Value
--- -----
token hvs.CAESILytrCcl_7yt_YRaXJKZf7Ch0KFvFg0I8cwHLzLJ8Yz7GiEKHGh2cy5yVDRMb0JmM2taS2JOaXdNdUlWakFMWU0Q9BE
token_accessor LT3pdtJWz9jxAdS6FYVevr7i
token_duration 768h
token_renewable true
token_policies ["default"]
identity_policies []
policies ["default"]
token_meta_role_name role-with-num-use
When replication breaks or the primary cluster is down, perform a login using same role-id and secret-id. Login would fail as primary is unable to write num_uses counter into storage.
vault@pr-sec:~/vault/plugins$ vault write -f auth/approle/login role_id=be2f555e-9243-385b-3b38-2d6547050a3f secret_id=2c2b37d2-74f8-6510-0399-9295a4acdc21
Error writing data to auth/approle/login: Error making API request.
URL: PUT http://192.168.105.75:8200/v1/auth/approle/login
Code: 500. Errors:
* request error returned from primary: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing: dial tcp 192.168.105.10:8201: connect: connection refused"
Case 2: let's create an app-role named role-with-num-uses-and-local-secret-ids with secret_id_num_uses set to a number along with local_secret_ids set to true. Fetch the role-id of the role. This can be performed on any cluster (Primary or Performance secondary):
vault@primary:~/vault$ vault write -f auth/approle/role/role-with-num-uses-and-local-secretId num_uses=10 local_secret_ids=true
Success! Data written to: auth/approle/role/role-with-num-uses-and-local-secretId
vault@ldap:~/vault$
vault@ldap:~/vault$ vault read auth/approle/role/role-with-num-uses-and-local-secretId/role-id
Key Value
--- -----
role_id 016720aa-024e-9f06-03ec-1dd1e92276c7
Generate a secret-id of the new app-role on the performance secondary cluster :
vault@pr-sec:~/vault/plugins$ vault write -f auth/approle/role/role-with-num-uses-and-local-secretId/secret-id
Key Value
--- -----
secret_id 2827b92c-82b8-8797-9de7-d1df4394d5f9
secret_id_accessor a49bed20-e2f0-d9a7-20e1-469cfb2c01f3
secret_id_num_uses 0
secret_id_ttl 0s
Perform a login using the role-id and secret-id on the performance secondary cluster.
vault@pr-sec:~/vault/plugins$ vault write -f auth/approle/login role_id=016720aa-024e-9f06-03ec-1dd1e92276c7 secret_id=2827b92c-82b8-8797-9de7-d1df4394d5f9
Key Value
--- -----
token hvs.CAESIFVT3twpytdy4_VzS-Alx051m-KkpHcFMZdD2mD0gvoqGiEKHGh2cy53YjNSSW5lQXFvbjJtWURoc0o5SVl0YmMQ0BI
token_accessor Fb9bmqZCh9b4Ie7kgQ7r7Ump
token_duration 768h
token_renewable true
token_policies ["default"]
identity_policies []
policies ["default"]
token_meta_role_name role-with-num-uses-and-local-secretid
When replication breaks or the primary cluster is down, perform a login using the same role-id and secret-id. Login would succeed as performance secondary does not need to write num_uses counter into the storage of primary cluster.
vault@pr-sec:~/vault/plugins$ vault write -f auth/approle/login role_id=016720aa-024e-9f06-03ec-1dd1e92276c7 secret_id=2827b92c-82b8-8797-9de7-d1df4394d5f9
Key Value
--- -----
token hvs.CAESIKlsyFgg6Lr8C3jOcSnxP7x5wWapj0RZqo-fOoQaynnFGiEKHGh2cy56bjJDVzdpdlp6UFhoVmg4VFRURXFQZzIQ4RI
token_accessor HKdIf18uUgYNnj8V891OXxIG
token_duration 768h
token_renewable true
token_policies ["default"]
identity_policies []
policies ["default"]
token_meta_role_name role-with-num-uses-and-local-secretid
Additional notes:
- Parameter local_secret_ids can only be set during role creation and once set, it can't be reset later.
- There is another parameter used for controlling the secret_id usage; i.e.; num_uses available on generate secret_id endpoint. This overrides the secret_id_num_uses role option when supplied. The behavior of approle login requests explained in the example works the same way irrespective of num_uses or secret_id_num_uses taking precedence.
- The approle auth method is primarily used for machine authentication, where the automated way of secret_id creation and login is performed by CI/CD tools. The example use case here is a representation using manual CLI commands.
References:
Approle recommended pattern and best practices