VRRP password is stored in clear text, can it be encrypted?

[Redfisky]

Describe the issue In VRRP authentication configuration, for example: auth_type PASS auth_pass xxxxx(password), the password is stored in plaintext, any method to improve security or adding encryption mechanism?

To Reproduce When configuring keepalived.conf VRRP parameters.

Expected behavior Password is encrypted thus make it safer.

Keepalived version v2.0.19

Details of any containerisation or hosted service (e.g. AWS) Run on Kubernetes as a pod. (Huawei FusionStage EulerOS 2.0)

Configuration file: Sorry for the chinese annotations here. auth_pass needs encryption.

global_defs {      #全局配置
   notification_email {        
#报警邮件发送给谁 
后端服务器故障时需要发送email通知以及email发送给哪些邮件地址邮件地址可以多个每行一个，如果是发到本机的用户邮箱格式：已存在的用户@主机名    
     acassen@firewall.loc
     failover@firewall.loc
     sysadmin@firewall.loc
   }
   notification_email_from Alexandre.Cassen@firewall.loc #通知邮件的发件人邮箱，可以随意自定义
   smtp_server 192.168.200.1     #邮件服务器地址
   smtp_connect_timeout 30      #件服务器连接的超时时间
   router_id LVS_DEVEL        #机器标识，可以不修改，多台机器此id可以相同
}

vrrp_instance VI_1 {      #vroute标识
    state MASTER          #当前节点的状态 主节点
    interface eth0        #发送vip通告的接口
    virtual_router_id 51  #虚拟路由的ID号是虚拟路由MAC的最后一位地址
    priority 100           #此节点的优先级主节点的优先级需要比其他节点高
    advert_int 1           #vip通告的时间间隔   
    authentication {       #认证配置
       auth_type PASS     #认证机制默认是明文
      auth_pass 1111     #随机字符当密码，要和虚拟路由器中其它路由器保持一致
    }
    virtual_ipaddress {   #vip
        192.168.100.41

    }

    track_interface {       #监控物理接口，如果出现故障会被标记为失败
    eth0
    eth1
    }
}
###########################################只要以上的配置把下面的都注释就可以实现
简单高可用此时只能实现主机故障|网络故障|keepalived进程停止时vip转移或者通过脚本实现其它服务的切换

virtual_server 192.168.100.41 80 {  #虚拟服务器所使用的VIP和端口和上面使用vip对应
    delay_loop 6          #健康状态检测间隔时间
    lb_algo rr             #lvs调度算法rr|wrr|lc|wlc|lblc|sh|dh
    lb_kind NAT            #lvs负载均衡模式NAT|DR|RUN
    nat_mask 255.255.255.0
    persistence_timeout 50  #持久连接时间
    protocol TCP            #使用的协议

    real_server 192.168.100.41 80 {    #节点服务器使用的IP及端口
        weight 1        
        SSL_GET {     #健康状态检测方法  
            url {
              path /    #检测的页面
              #digest ff20ad2481f97b1754ef3e12ecd3a9cc  #检查的摘要信息
              status_code 200 #检查的返回状态码
            }
            url {
              path /mrtg/
              digest 9b3a0c85a887a256d6939da88aabd8cd
            }
            connect_timeout 3           #连接超时时间
            nb_get_retry 3              #重连次数
            delay_before_retry 3        #重连间隔
        }
    }
}

virtual_server 10.10.10.2 1358 {
    delay_loop 6
    lb_algo rr 
    lb_kind NAT
    persistence_timeout 50
    protocol TCP

    sorry_server 192.168.200.200 1358

    real_server 192.168.200.2 1358 {
        weight 1
        HTTP_GET {
            url { 
              path /testurl/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            url { 
              path /testurl2/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            url { 
              path /testurl3/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }

    real_server 192.168.200.3 1358 {
        weight 1
        HTTP_GET {
            url { 
              path /testurl/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334c
            }
            url { 
              path /testurl2/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334c
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

virtual_server 10.10.10.3 1358 {
    delay_loop 3
    lb_algo rr 
    lb_kind NAT
    nat_mask 255.255.255.0
    persistence_timeout 50
    protocol TCP

    real_server 192.168.200.4 1358 {
        weight 1
        HTTP_GET {
            url { 
              path /testurl/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            url { 
              path /testurl2/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            url { 
              path /testurl3/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }

    real_server 192.168.200.5 1358 {
        weight 1
        HTTP_GET {
            url { 
              path /testurl/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            url { 
              path /testurl2/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            url { 
              path /testurl3/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

[pqarmitage]

@Redfisky Please see RFC 3768 (the updated VRRPv2 RFC) section 5.3.6:

Note:  Earlier version of the VRRP specification had several defined
   authentication types [RFC2338].  These were removed in this
   specification because operational experience showed that they did not
   provide any real security and would only cause multiple masters to be
   created.

and also see RFC 5798 (the current VRRP RFC) section 9 and RFC 3768 (the updated VRRPv2 RFC) section 10:

   VRRP for IPvX does not currently include any type of authentication.
   Earlier versions of the VRRP (for IPv4) specification included
   several types of authentication ranging from none to strong.
   Operational experience and further analysis determined that these did
   not provide sufficient security to overcome the vulnerability of
   misconfigured secrets, causing multiple Masters to be elected. 
...

We maintain authentication for backward compatibility with the original version of VRRPv2. However, since authentication is not supported in VRRPv3 and is no longer part of VRRPv2 and is not considered to provide sufficient security to be worth while, there does not appear to be any benefit in attempting to protect the password in the configuration.

[Redfisky]

@Redfisky Please see RFC 3768 (the updated VRRPv2 RFC) section 5.3.6:

Note:  Earlier version of the VRRP specification had several defined
   authentication types [RFC2338].  These were removed in this
   specification because operational experience showed that they did not
   provide any real security and would only cause multiple masters to be
   created.

and also see RFC 5798 (the current VRRP RFC) section 9 and RFC 3768 (the updated VRRPv2 RFC) section 10:

   VRRP for IPvX does not currently include any type of authentication.
   Earlier versions of the VRRP (for IPv4) specification included
   several types of authentication ranging from none to strong.
   Operational experience and further analysis determined that these did
   not provide sufficient security to overcome the vulnerability of
   misconfigured secrets, causing multiple Masters to be elected. 
...

We maintain authentication for backward compatibility with the original version of VRRPv2. However, since authentication is not supported in VRRPv3 and is no longer part of VRRPv2 and is not considered to provide sufficient security to be worth while, there does not appear to be any benefit in attempting to protect the password in the configuration.

Thank you for reply.