u/ankitjindal9404

Hey all, looking for a sanity check on our approach.

Stack: AWS + Kubernetes. We deploy with plain helm install (no GitOps tool like Argo/Flux).

Current setup: Our Helm values.yaml has hardcoded secrets (env vars) in it. Right now this file lives on our Jenkins server, not in any repo.

The plan: We want to move values.yaml into our Git repo so we can version it properly. The obvious problem — we can't commit hardcoded secrets in plain text.

Our idea: Use git-crypt to encrypt the file at rest in the repo, so secrets are scrambled on the remote and only unlock for people with the key.

Questions:

• Any real-world gotchas we should know before committing to it?
• Since we're already on AWS, would you skip file encryption entirely and go with something like External Secrets Operator + AWS Secrets Manager? Or is that overkill for a small team? Also curious where SOPS (with AWS KMS) or Sealed Secrets fit in.

For context: we're a small-ish team and just want a clean, low-friction way to keep secrets versioned without leaking them.

Appreciate any input 🙏

Hey all, looking for a sanity check on our approach.

Stack: AWS + Kubernetes. We deploy with plain helm install (no GitOps tool like Argo/Flux).

Current setup: Our Helm values.yaml has hardcoded secrets (env vars) in it. Right now this file lives on our Jenkins server, not in any repo.

The plan: We want to move values.yaml into our Git repo so we can version it properly. The obvious problem — we can't commit hardcoded secrets in plain text.

Our idea: Use git-crypt to encrypt the file at rest in the repo, so secrets are scrambled on the remote and only unlock for people with the key.

Questions:

• Any real-world gotchas we should know before committing to it?
• Since we're already on AWS, would you skip file encryption entirely and go with something like External Secrets Operator + AWS Secrets Manager? Or is that overkill for a small team? Also curious where SOPS (with AWS KMS) or Sealed Secrets fit in.

For context: we're a small-ish team and just want a clean, low-friction way to keep secrets versioned without leaking them.

Appreciate any input 🙏

Hey all, looking for a sanity check on our approach.

Stack: AWS + Kubernetes. We deploy with plain helm install (no GitOps tool like Argo/Flux).

Current setup: Our Helm values.yaml has hardcoded secrets (env vars) in it. Right now this file lives on our Jenkins server, not in any repo.

The plan: We want to move values.yaml into our Git repo so we can version it properly. The obvious problem — we can't commit hardcoded secrets in plain text.

Our idea: Use git-crypt to encrypt the file at rest in the repo, so secrets are scrambled on the remote and only unlock for people with the key.

Questions:

• Any real-world gotchas we should know before committing to it?
• Since we're already on AWS, would you skip file encryption entirely and go with something like External Secrets Operator + AWS Secrets Manager? Or is that overkill for a small team? Also curious where SOPS (with AWS KMS) or Sealed Secrets fit in.

For context: we're a small-ish team and just want a clean, low-friction way to keep secrets versioned without leaking them.

Appreciate any input 🙏

We run Trivy in our Jenkins pipeline — both trivy fs and trivy image. There's a security gate stage that block the pipeline if there are any CRITICAL or HIGH findings.

The problem: a dev resolves 2-3 Trivy issues, and a couple days later they're back / new ones show up, and the build blocks again. So devs are basically fixing Trivy findings every other day.

I know part of this is just the DB being fresh — new CVEs get disclosed daily, that's expected. But the every-build hard block is painful.

I was thinking of running the blocking gate only once a week instead of on every build. But I can already see the flaw: code that deploys mid-week would ship with known issues, and if a genuinely exploitable fixable CVE drops on a Monday we'd be shipping it for 6 days before the gate catches it.

So my questions for people running this in prod:

• Do you gate on every build, or on a schedule?
• Do you block on all CRITICAL/HIGH, or only ones that actually have a fix available (--ignore-unfixed)?

We run Trivy in our Jenkins pipeline — both trivy fs and trivy image. There's a security gate stage that block the pipeline if there are any CRITICAL or HIGH findings.

The problem: a dev resolves 2-3 Trivy issues, and a couple days later they're back / new ones show up, and the build blocks again. So devs are basically fixing Trivy findings every other day.

I know part of this is just the DB being fresh — new CVEs get disclosed daily, that's expected. But the every-build hard block is painful.

I was thinking of running the blocking gate only once a week instead of on every build. But I can already see the flaw: code that deploys mid-week would ship with known issues, and if a genuinely exploitable fixable CVE drops on a Monday we'd be shipping it for 6 days before the gate catches it.

So my questions for people running this in prod:

• Do you gate on every build, or on a schedule?
• Do you block on all CRITICAL/HIGH, or only ones that actually have a fix available (--ignore-unfixed)?

Currently we keep our DevOps-related files (Dockerfile, values.yaml, etc.) on the Jenkins server instead of in the repo. During pipeline runs, we copy these files in at runtime.

I'm considering moving these files directly into the repository instead. The problem: if a developer accidentally edits the Dockerfile or values.yaml, it could cause issues.

So I want a way to either:

1. Prevent developers from editing those specific files, or
2. Require PR approval specifically for changes to those files

What's the best approach for this?

Currently we keep our DevOps-related files (Dockerfile, values.yaml, etc.) on the Jenkins server instead of in the repo. During pipeline runs, we copy these files in at runtime.

I'm considering moving these files directly into the repository instead. The problem: if a developer accidentally edits the Dockerfile or values.yaml, it could cause issues.

So I want a way to either:

1. Prevent developers from editing those specific files, or
2. Require PR approval specifically for changes to those files

What's the best approach for this?

Hi everyone,

Hope you're all doing well.

I'm a fresher with about 6 months of experience, currently working as a DevOps Engineer at my company.

I'd love to hear from seniors with 4-5+ years of experience, especially those in product-based companies, MNCs, or well-paying roles: how do you keep upgrading your skills as a DevOps engineer? Do you study or practice daily/weekly outside of work, or does your office work alone keep you sharp?

I can dedicate 1-2 hours daily to self-improvement. I'd really appreciate your suggestions on how I should spend this time to grow into the best version of myself as a DevOps engineer.

Thanks in advance!

Hi everyone,

Hope you're all doing well.

I'm a fresher with about 6 months of experience, currently working as a DevOps Engineer at my company.

I'd love to hear from seniors with 4-5+ years of experience, especially those in product-based companies, MNCs, or well-paying roles: how do you keep upgrading your skills as a DevOps engineer? Do you study or practice daily/weekly outside of work, or does your office work alone keep you sharp?

I can dedicate 1-2 hours daily to self-improvement. I'd really appreciate your suggestions on how I should spend this time to grow into the best version of myself as a DevOps engineer.

Thanks in advance!

Hi everyone,

Hope you're all doing well.

I'm a fresher with about 6 months of experience, currently working as a DevOps Engineer at my company.

I'd love to hear from seniors with 4-5+ years of experience, especially those in product-based companies, MNCs, or well-paying roles: how do you keep upgrading your skills as a DevOps engineer? Do you study or practice daily/weekly outside of work, or does your office work alone keep you sharp?

I can dedicate 1-2 hours daily to self-improvement. I'd really appreciate your suggestions on how I should spend this time to grow into the best version of myself as a DevOps engineer.

Thanks in advance!