Hakbang 3 - Magdagdag ng mga lihim sa Vault

3.1 Gumawa ng Dynamic Group at IAM Policy​

Ang Dynamic Group at IAM Policy ay magkasamang nagbibigay sa mga OKE cluster node ng pahintulot na i-sync ang mga lihim ng Vault sa Kubernetes.

Palitan ang <dynamic-group-name> at <iam-policy-name> ng mga angkop na value para sa iyong environment.

oci iam dynamic-group create --name "<dynamic-group-name>" \
--description "Dynamic Group for OKE cluster nodes" \
--matching-rule "instance.compartment.id='${compartment_ocid}'"

oci iam policy create -c ${compartment_ocid} --name '<iam-policy-name>' \
--description "Oracle vault secrets access for OKE" \
--statements "[\"Allow dynamic-group <dynamic-group-name> to read secret-family in compartment <oracle-compartment-name> where target.vault.id='${vault_ocid}'\"]"

3.2 Magdagdag ng mga password ng MongoDB sa lihim ng Vault​

Tandaan: kung wala kang planong mag-manage ng mga policy o gumamit ng Asynchronous API, maaari mong laktawan ang hakbang na ito.

Upang pahintulutan ang Glasswall Halo Policy Management API na gumawa at mag-manage ng mga policy sa MongoDB, at ang Asynchronous API na magproseso ng mga request, dapat i-deploy ang MongoDB gamit ang Helm charts.

Ang MongoDB Helm chart ay gumagawa ng dalawang user. Dapat i-store ang mga password ng mga user na ito sa isang lihim ng Vault.

Ang sensitibong data, gaya ng mga password, ay dapat i-store bilang mga key value pair sa JSON format sa loob ng lihim ng Vault.

Kung kailangan ang mga password mula sa maraming hakbang, gumawa ng iisang JSON object na naglalaman ng lahat ng password o i-update ang umiiral na JSON object gamit ang mga karagdagang value.

{
    "mongodb-cdrp-password": "",
    "mongodb-admin-password": ""
}

3.3 [Opsyonal] Magdagdag ng mga credential ng ReversingLabs​

Upang maisama ang Halo sa ReversingLabs, i-store ang mga kredensyal ng ReversingLabs sa Key Vault.

{
    "reversinglabs_username": "",
    "reversinglabs_password": ""
}

3.4 [Opsyonal] Magdagdag ng mga sertipiko ng ICAP mTLS​

Maaaring i-configure ang mga ICAP server para sa mutual client authentication gamit ang mga sertipiko ng mTLS.

Ang mga sertipiko ay mina-mount sa mga pod ng ICAP server bilang mga Kubernetes secret. Idagdag ang mga sertipiko ng server at mga sertipiko ng certificate authority sa Oracle Vault upang ma-sync ang mga ito sa mga Kubernetes secret.

{ 
    "tls-server-cert": "<content of mtls-server-cert.pem>",
    "tls-server-key": "<content of mtls-server-key.pem>",
    "tls-cafile": "<content of mtls-ca-cert.pem>"
}